Description du projet
TraduitNous avons besoin d'un système de web scraping de production qui, selon un calendrier quotidien, collecte des données structurées à partir de 5 à 8 sites web et les transforme en un format adapté à l'analyse. Ce n'est pas un script ponctuel mais un service qui fonctionne sans surveillance chaque jour, survit aux changements de balisage des sources, réduit respectueusement la charge lorsqu'un site web le demande, et ne plante pas complètement si l'une des ressources cibles se casse. Certaines sources sont du HTML statique simple, d'autres sont des SPAs JavaScript lourds, donc le crawler doit gérer les deux avec confiance.
Tout aussi important est ce qui se passe après le chargement de la page. Le HTML brut doit se transformer en enregistrements vérifiés et dédupliqués, et les prix, dates et numéros de téléphone doivent être normalisés en formats uniformes avant d'atteindre la base de données. Il est logique de ne stocker que les données nouvelles ou modifiées, donc nous avons besoin d'une logique incrémentale. Au-delà de cela, la transparence opérationnelle est importante pour nous : un tableau de bord montrant les taux de réussite des exécutions et les volumes, des notifications pour les échecs et les anomalies de données, et un déploiement reproductible qui peut être mis en place à partir de zéro sans connaissance tribale.
Les sites web cibles spécifiques sont confidentiels et partagés sous NDA après accord des termes. Dans votre réponse, parlez des protections anti-bot que vous avez rencontrées et de la manière dont vous avez maintenu le parseur stable au fil du temps. Portée complète du travail ci-dessous.
1. Architecture du scraper
— Scrapy + rotation de proxy et pool d'User-Agent
— Playwright/Selenium pour les sites JS
— Contournement de CAPTCHA (2captcha / anti-captcha)
— Limitation de taux, conformité robots.txt
2. Pipeline de données
— HTML vers JSON structuré
— Validation et déduplication
— Normalisation des prix, dates, numéros de téléphone
— Stockage PostgreSQL avec conception de schéma
— Mises à jour incrémentales (uniquement nouveaux/enregistrés modifiés)
3. Surveillance et opérations
— Tableau de bord : succès d'exécution, comptes d'enregistrements, erreurs
— Alertes Slack/email sur les échecs
— Déploiement Docker Compose
— Planification Cron avec logique de réessai
Sites web cibles
— Confidentiels (NDA) — détails après accord
— Mélange de sites statiques et de sites SPA
Livrables
— Code source avec tests
— Configuration Docker Compose
— Migrations de schéma de base de données
— Runbook et configuration de surveillance
Tout aussi important est ce qui se passe après le chargement de la page. Le HTML brut doit se transformer en enregistrements vérifiés et dédupliqués, et les prix, dates et numéros de téléphone doivent être normalisés en formats uniformes avant d'atteindre la base de données. Il est logique de ne stocker que les données nouvelles ou modifiées, donc nous avons besoin d'une logique incrémentale. Au-delà de cela, la transparence opérationnelle est importante pour nous : un tableau de bord montrant les taux de réussite des exécutions et les volumes, des notifications pour les échecs et les anomalies de données, et un déploiement reproductible qui peut être mis en place à partir de zéro sans connaissance tribale.
Les sites web cibles spécifiques sont confidentiels et partagés sous NDA après accord des termes. Dans votre réponse, parlez des protections anti-bot que vous avez rencontrées et de la manière dont vous avez maintenu le parseur stable au fil du temps. Portée complète du travail ci-dessous.
1. Architecture du scraper
— Scrapy + rotation de proxy et pool d'User-Agent
— Playwright/Selenium pour les sites JS
— Contournement de CAPTCHA (2captcha / anti-captcha)
— Limitation de taux, conformité robots.txt
2. Pipeline de données
— HTML vers JSON structuré
— Validation et déduplication
— Normalisation des prix, dates, numéros de téléphone
— Stockage PostgreSQL avec conception de schéma
— Mises à jour incrémentales (uniquement nouveaux/enregistrés modifiés)
3. Surveillance et opérations
— Tableau de bord : succès d'exécution, comptes d'enregistrements, erreurs
— Alertes Slack/email sur les échecs
— Déploiement Docker Compose
— Planification Cron avec logique de réessai
Sites web cibles
— Confidentiels (NDA) — détails après accord
— Mélange de sites statiques et de sites SPA
Livrables
— Code source avec tests
— Configuration Docker Compose
— Migrations de schéma de base de données
— Runbook et configuration de surveillance
Développement de logiciels Espèces, Virement bancaire
