Créer un pipeline de données avec un web scraperSuivez, gérez et visualisez vos données

Un scraper web n'est que la première étape. Le problème plus difficile et plus utile est de transformer un flux de pages scrapées en un pipeline de données que vous pouvez suivre, gérer et visualiser : quelque chose qui collecte selon un planning, place des lignes propres dans un store, vous avertit quand une exécution échoue et alimente un graphique qu'un non-ingénieur peut lire. Ce guide construit cette petite boucle de bout en bout en Python, avec la Crawlbase Crawling API et le Crawler asynchrone comme colonne vertébrale de collecte et d'opérations.

La portée est délibérément pratique. Nous allons collecter des données de listing public avec une requête, stocker chaque ligne dans SQLite avec un timestamp de capture, agréger avec une seule requête SQL et décrire la couche de surveillance et de visualisation qui se trouve au-dessus. L'intérêt d'un scraper web pour suivre, gérer et visualiser un pipeline de données est qu'aucune pièce individuelle n'est complexe : la valeur est dans le câblage de toutes en une boucle qui fonctionne sans que vous la surveilliez.

Ce qu'est réellement un pipeline de données

Débarrassez-le du jargon et un pipeline de données déplace des données de l'endroit où elles vivent vers l'endroit où vous pouvez les utiliser, en les transformant en chemin. La forme standard est ETL : extraire les données brutes de la source, les transformer en une forme structurée propre, et les charger dans un store que vous pouvez interroger. Un pipeline de scraping a la même forme avec le web comme source.

Pour notre boucle, les quatre étapes se mappent clairement : collecter la page avec la Crawling API, stocker les lignes normalisées dans une base de données, planifier et surveiller les exécutions pour que la collecte continue et que les échecs remontent, et visualiser le résultat pour que les données guident une décision. Chaque étape représente quelques lignes de code ou une fonctionnalité gérée. L'ingénierie consiste à les garder séparées pour qu'un changement dans l'une ne casse pas les autres.

Pourquoi le scraper est la partie fragile

Le stockage, la planification et les graphiques sont des problèmes bien balisés avec des outils matures. La collecte est là où les pipelines échouent réellement, parce que la source résiste. Les cibles modernes rendent le contenu côté client, donc une simple requête HTTP vous remet une coquille vide, et elles signalent le trafic automatisé rapidement, donc les IPs de datacenter et les patterns de requêtes ressemblant à des bots se voient challengés ou bloqués avant de voir quelconque donnée.

C'est le même mur que vous rencontrez dans tout travail de scraping web e-commerce : l'analyseur est facile, l'accès ne l'est pas. Vous pouvez assembler la couche d'accès vous-même avec un navigateur sans interface graphique et un pool de proxies rotatifs, mais relier ces éléments et les maintenir en état représente l'essentiel du travail. La Crawling API regroupe le rendu, la rotation des IPs et les nouvelles tentatives en cas de blocage en un seul appel, pour que l'étape la plus fragile du pipeline devienne une seule fonction que vous n'avez pas à surveiller. Cette fiabilité est ce qui rend le reste de la boucle valant la peine d'être construit.

Configurer le projet

Vous avez besoin de Python 3 et de pip. Créez un projet, un environnement virtuel et installez l'unique dépendance qui communique avec la Crawling API. Tout le reste (SQLite, le client HTTP) est livré avec la bibliothèque standard ou est déjà installé.

python3 --version

mkdir scrape-pipeline && cd scrape-pipeline
python3 -m venv .venv && source .venv/bin/activate
pip install requests

Vous avez aussi besoin d'un compte Crawlbase et d'un token API, que vous obtenez depuis le tableau de bord après inscription. Le niveau gratuit suffit pour construire et tester toute la boucle. Insérez le token dans le code partout où vous voyez _YOUR_TOKEN_.

Collecter : récupérer une page rendue avec la Crawling API

L'étape de collecte envoie une URL à la Crawling API et récupère le HTML finalisé en retour. Deux options comptent pour un site qui rend côté client : passer javascript=true exécute la page dans un vrai navigateur avant de la renvoyer, et ajax_wait=true attend que le contenu asynchrone se charge. L'API fait tourner l'IP et réessaie sur les blocages côté serveur, donc cet unique appel remplace un navigateur sans interface graphique plus un pool de proxies.

import requests
from bs4 import BeautifulSoup

TOKEN = "_YOUR_TOKEN_"

def fetch(url):
    # One call handles rendering, IP rotation, and retries.
    resp = requests.get(
        "https://api.crawlbase.com/",
        params={
            "token": TOKEN,
            "url": url,
            "javascript": "true",
            "ajax_wait": "true",
        },
    )
    resp.raise_for_status()
    return resp.text

Cela vous donne un vrai balisage avec des listings dedans au lieu de la coquille vide qu'une simple récupération renvoie. Confirmez cela avant d'écrire un seul sélecteur : si fetch renvoie le DOM rendu, l'étape la plus difficile est résolue.

Transformer : analyser les lignes et normaliser à la capture

L'analyse transforme le HTML en enregistrements structurés. La règle qui vous sauve plus tard est de normaliser à la capture : stocker le prix comme un nombre réel, conserver un timestamp propre, et ne jamais vous promettre que vous le « nettoierez plus tard ». Mappez les sélecteurs au vrai balisage de votre cible ; la forme ci-dessous est le modèle.

import re
from datetime import datetime, timezone

def parse_products(html):
    soup = BeautifulSoup(html, "html.parser")
    captured = datetime.now(timezone.utc).isoformat()
    rows = []
    for card in soup.select(".product-card"):
        raw_price = card.select_one(".price").get_text(strip=True)
        rows.append({
            "sku": card["data-sku"],
            "title": card.select_one("h3").get_text(strip=True),
            "price": float(re.sub(r"[^\d.]", "", raw_price)),
            "captured_at": captured,
        })
    return rows

Le champ captured_at est ce qui transforme un instantané en pipeline. Avec un timestamp sur chaque ligne, le même SKU scrapé quotidiennement devient un historique de prix que vous pouvez représenter graphiquement, pas seulement un chiffre actuel. Si une cible vous bloque ou rend le prix en JavaScript, vous ne réécrivez pas cet analyseur ; vous avez déjà résolu l'accès dans fetch. Cette séparation, l'analyse comme votre code stable et l'accès comme un paramètre que vous ajustez par cible, est toute la raison pour laquelle la boucle survit à un durcissement des défenses d'un site. Pour le guide complet, voyez comment scraper des sites web sans être bloqué.

Stocker : charger les lignes dans une base de données interrogeable

Les fichiers plats conviennent pendant que vous itérez, mais une base de données est ce qui rend les données gérables et traçables. SQLite est livré avec Python, ne nécessite aucun serveur et vous donne SQL dès le premier jour. Créez une table de sorte que les exécutions répétées ajoutent de l'historique plutôt que de l'écraser, puis écrivez chaque lot en une seule transaction.

import sqlite3

def init_db(path="pipeline.db"):
    conn = sqlite3.connect(path)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS products (
            sku         TEXT,
            title       TEXT,
            price       REAL,
            captured_at TEXT
        )
    """)
    return conn

def save(conn, rows):
    conn.executemany(
        "INSERT INTO products VALUES (:sku, :title, :price, :captured_at)",
        rows,
    )
    conn.commit()

Maintenant, reliez les trois étapes en un seul script exécutable. Voici le pipeline en miniature : collecter, analyser, stocker, avec le nombre de lignes affiché pour qu'un planificateur ou un humain puisse voir que l'exécution a fait quelque chose.

def run(url):
    conn = init_db()
    rows = parse_products(fetch(url))
    save(conn, rows)
    print(f"stored {len(rows)} rows")
    conn.close()

if __name__ == "__main__":
    run("https://example.com/category/widgets")

Visualiser : agréger avec une requête, puis créer un graphique

Un store plein de lignes horodatées n'est utile qu'une fois qu'il répond à une question. Parce que les données sont en SQL, l'agrégation est une requête, pas un script. Voici la tendance de prix pour un SKU sur les 30 derniers jours, le type de résultat qui alimente un graphique en courbes.

SELECT date(captured_at) AS day,
       AVG(price)        AS avg_price,
       MIN(price)        AS low_price,
       MAX(price)        AS high_price
FROM products
WHERE sku = 'WIDGET-42'
  AND captured_at >= date('now', '-30 days')
GROUP BY day
ORDER BY day;

Vous avez deux façons de l'afficher. La voie rapide est de pointer un outil BI comme Power BI, Metabase ou Grafana directement sur le fichier de base de données et de construire un tableau de bord sans code supplémentaire. La voie programmatique est d'exécuter la requête en Python et de rendre la série vous-même, ce qui est pratique quand le graphique fait partie d'un rapport que vous générez selon un planning.

import sqlite3
import matplotlib.pyplot as plt

conn = sqlite3.connect("pipeline.db")
rows = conn.execute(QUERY, ("WIDGET-42",)).fetchall()
days = [r[0] for r in rows]
avg_price = [r[1] for r in rows]

plt.plot(days, avg_price, marker="o")
plt.title("WIDGET-42 average price, last 30 days")
plt.savefig("trend.png")

Dans tous les cas, le graphique est en aval de lignes propres et horodatées. Réussissez la collecte et le stockage et la couche de visualisation est interchangeable : échangez matplotlib contre un tableau de bord BI sans toucher au scraper.

Planifier et surveiller : maintenir la boucle en fonctionnement

Un pipeline qui tourne une fois est un script. Pour le suivre et le gérer, vous devez le faire tourner selon un planning et qu'il vous dise quand il échoue. Il y a deux couches à cela, et elles répondent à des questions différentes.

Planifier la collecte. La version la plus simple est une entrée cron qui exécute le script chaque nuit. Sur Linux ou macOS, 0 2 * * * /path/.venv/bin/python /path/run.py collecte à 2h du matin chaque jour. Quand le nombre de cibles augmente, un planificateur de flux de travail comme Airflow ou un service cron géré vous donne des nouvelles tentatives et un historique d'exécution, mais cron suffit pour commencer.

Surveiller la collecte. Cron vous dira que le script s'est terminé ; il ne vous dira pas que le scrape a renvoyé des résultats maigres parce qu'une cible a changé son balisage ou commencé à challenger vos requêtes. C'est là que le Crawler asynchrone gagne sa place. Au lieu de récupérer des pages une par une et de bloquer, vous poussez des URLs vers le Crawler et il les crawle de manière asynchrone, puis livre chaque page finalisée à un webhook que vous hébergez. La surveillance intégrée dans le tableau de bord montre le volume de requêtes, les taux de succès et d'échec, et les crédits utilisés, pour que vous observiez la santé de la collecte sans l'instrumenter vous-même.

# Push a URL to the async Crawler; results arrive at your webhook.
requests.get(
    "https://api.crawlbase.com/",
    params={
        "token": TOKEN,
        "url": "https://example.com/category/widgets",
        "callback": "https://your-app.example.com/webhook",
        "javascript": "true",
    },
)

Avec la collecte asynchrone, votre gestionnaire de webhook exécute les mêmes fonctions parse_products et save de tout à l'heure ; seul le déclencheur change d'une récupération bloquante à un callback livré. C'est ce qui permet au pipeline de passer d'une URL à des milliers sans que votre processus reste assis à attendre. Si vous n'avez besoin que d'un flux analysé sur des cibles courantes plutôt que du HTML brut, la Crawling API renvoie du JSON structuré directement, et une configuration Smart AI Proxy plus légère couvre le cas où vous avez juste besoin d'une IP rotative devant votre propre client.

Gérer le pipeline dans le temps

Une fois que la boucle tourne sans surveillance, la gestion devient une affaire de trois habitudes. Surveillez le tableau de bord de monitoring pour un taux d'échec croissant, qui signifie généralement qu'une cible a changé et qu'un sélecteur doit être mis à jour, la maintenance de routine que tout scraper en production nécessite. Gardez un timestamp de capture sur chaque ligne pour que le store soit une piste d'audit, pas seulement un instantané. Et traitez la collecte et l'analyse comme des préoccupations séparées : quand un site durcit ses défenses, vous ajustez le paramètre d'accès, et le code de stockage, de requête et de graphique ne bouge jamais.

Cette séparation est la conception durable. Pour mettre les chiffres en perspective : environ 2,5 quintillions d'octets de données sont créés chaque jour, et les équipes qui en transforment la moindre tranche en décisions sont celles qui disposent d'un pipeline en lequel elles peuvent avoir confiance pour continuer à fonctionner. Un scraper web qui suit, gère et visualise un pipeline de données est la façon d'y arriver sans rester debout à le surveiller. Pour en savoir plus sur la façon dont l'accès géré diffère de l'exploitation de votre propre infrastructure, qu'est-ce qu'un serveur proxy est un bon point de départ.

Foire aux questions

Qu'est-ce qu'un pipeline de données dans le contexte du web scraping ?

C'est le chemin que parcourent les données scrapées depuis le site source jusqu'à un endroit où vous pouvez les utiliser. Dans un pipeline de scraping, vous collectez la page, transformez le HTML brut en lignes structurées propres, chargez ces lignes dans un store interrogeable, puis planifiez et surveillez l'ensemble pour qu'il continue à fonctionner. Le scraper web est l'étape de collecte ; le pipeline est tout ce qui transforme sa sortie en quelque chose de traçable et visualisable.

Pourquoi utiliser la Crawling API plutôt qu'une simple requête HTTP pour collecter des données ?

Parce que la plupart des cibles utiles rendent le contenu côté client et bloquent le trafic ressemblant à des bots. Une simple requête renvoie une coquille vide ou une page de challenge, pas les données. La Crawling API rend la page dans un vrai navigateur, fait tourner l'IP sur un large pool résidentiel et de datacenter, et réessaie sur les blocages, pour que l'étape de collecte de votre pipeline reste fiable sans que vous exploitiez un parc de navigateurs sans interface graphique et un pool de proxies.

Comment suivre et surveiller les exécutions du scraper dans le pipeline ?

Planifiez la collecte avec cron ou un planificateur de flux de travail pour qu'elle tourne seule, et estampillez chaque ligne stockée avec un timestamp de capture pour pouvoir auditer ce qui a tourné et quand. Pour la santé de la collecte, le Crawler asynchrone livre les résultats à un webhook et le tableau de bord Crawlbase suit le volume de requêtes, les taux de succès et d'échec, et les crédits utilisés, pour qu'un taux d'échec croissant signale une cible qui a changé avant que les mauvaises données s'accumulent.

Quels outils de base de données et de visualisation fonctionnent le mieux pour un pipeline de scraping ?

SQLite est le point de départ le plus facile car il est livré avec Python et ne nécessite aucun serveur, et Postgres est la progression naturelle en volume. Pour la visualisation, pointez un outil BI comme Power BI, Metabase, Grafana ou Tableau directement sur la base de données, ou rendez des graphiques en code avec matplotlib quand vous les voulez dans un rapport généré selon un planning. Parce que les données sont en SQL, la couche de visualisation est interchangeable.

Quelle est la différence entre la Crawling API et le Crawler asynchrone ?

La Crawling API est synchrone : vous envoyez une URL et attendez la page finalisée dans la réponse, ce qui est idéal pour un scraping unique ou une petite boucle. Le Crawler asynchrone est fait pour la mise à l'échelle : vous poussez de nombreuses URLs, il les crawle en arrière-plan et livre chaque résultat à un webhook que vous hébergez, avec surveillance dans le tableau de bord. Les deux partagent le même moteur de rendu et anti-blocage ; vous choisissez celui qui convient à votre débit.

Comment maintenir le pipeline en fonctionnement quand un site cible change son layout ?

Anticipez la dérive des sélecteurs et concevez pour elle. Gardez votre analyseur séparé de votre couche d'accès pour qu'un changement de layout ne touche que les sélecteurs, pas le code de récupération, de stockage ou de graphique. Surveillez le tableau de bord de monitoring pour un taux d'échec croissant ou des résultats maigres, ce qui est le signal de réinspecter la page en direct et de mettre à jour les sélecteurs. Cette maintenance périodique est normale pour tout scraper en production, ce n'est pas le signe que le pipeline est cassé.

BA

Bilal Ahmed

Ingénieur logiciel · Crawlbase

Ingénieur logiciel auteur de certains des articles les plus lus du blog Crawlbase, sur le web scraping, les proxys et l'outillage de données.