Pipeline de scraping robuste

Problème

Un script artisanal mélange souvent navigation, sélecteurs, transformation et stockage. Au premier changement de DOM, il renvoie silencieusement des données vides, duplique des éléments ou relance trop agressivement la source.

Architecture

Source autorisée
  → planificateur / RequestQueue
  → fetch HTTP ou navigateur selon nécessité
  → extraction versionnée
  → validation du contrat
  → normalisation + identité stable
  → upsert / Dataset
  → métriques, alertes et échantillons de preuve

Séparer au minimum discovery, fetch, extract, normalize, validate, persist et observe. Un changement de sélecteur ne doit pas modifier la logique de stockage.

Choix du moteur

1. Préférer une API publique/documentée si elle existe et si ses conditions le permettent.
2. Utiliser un client HTTP + parseur HTML pour le contenu serveur : moins de ressources, plus simple à tester.
3. Passer à Playwright/Puppeteer uniquement pour le rendu JavaScript, les interactions ou les données absentes du HTML/réseau accessible.
4. Ne pas contourner authentification, contrôle d'accès, CAPTCHA ou protections sans autorisation explicite.

Avec Crawlee : CheerioCrawler convient à l'HTML statique ; PlaywrightCrawler aux parcours réellement dynamiques ; RequestQueue, Router, Dataset, SessionPool et AutoscaledPool fournissent les briques d'exploitation.

Contrat de données

• Définir un schéma typé avec champs requis, optionnels, formats, unité, provenance, scraped_at et version d'extracteur.
• Produire une clé stable métier ; l'URL seule n'est pas toujours une identité.
• Distinguer absent, vide et erreur d'extraction.
• Rejeter ou mettre en quarantaine les enregistrements invalides ; ne pas les transformer silencieusement en null.
• Conserver un petit échantillon HTML/JSON ou une empreinte pour expliquer les régressions, dans le respect de la minimisation des données.

Résilience respectueuse

• Concurrence bornée par hôte, délais, retries limités et backoff exponentiel avec jitter.
• Respecter robots.txt, CGU, licences, données personnelles et demandes du propriétaire ; identifier le crawler lorsque pertinent.
• Utiliser cache et requêtes conditionnelles (ETag, If-Modified-Since) pour ne pas retélécharger inutilement.
• Dédupliquer la file et rendre l'écriture idempotente.
• Interrompre automatiquement si le taux d'erreur, de challenge ou de données invalides dépasse le seuil.

Observabilité minimale

Mesurer par source et version : URLs découvertes/traitées/échouées, latence, volume, retries, codes HTTP, invalidation de schéma, doublons, fraîcheur du dernier succès et évolution du nombre d'items. Une exécution « verte » avec zéro item nouveau doit pouvoir être distinguée d'un extracteur cassé.

Tests et maintenance

• Fixtures HTML/JSON représentatives et tests unitaires d'extraction.
• Test d'intégration léger sur une page autorisée, avec budget de requêtes.
• Canari quotidien sur quelques URLs avant un crawl complet.
• Sélecteurs basés sur sémantique/structure stable ; éviter les classes générées.
• Runbook : désactiver la source, restaurer la dernière donnée saine, mettre à jour la fixture et incrémenter la version.

Critères de livraison

• Deux exécutions identiques ne créent aucun doublon.
• Un DOM incomplet provoque une erreur explicite ou une quarantaine.
• La reprise après arrêt n'efface ni ne retrait les succès.
• Les limites de charge et la base légale/permission sont documentées par source.

Références

• Crawlee
• Apify Academy
• [[KNOW-PAT-233]] — pipeline ETL et observabilité
• [[KNOW-REF-061]] — parcours et outils de scraping sélectionnés