Développement Web

Web scraping en Python : le guide complet (2026)

16 min de lecture

Une part énorme de l’information utile vit sur des pages web, mais sous une forme faite pour l’œil humain, pas pour un programme : des prix éparpillés dans des tableaux, des annonces réparties sur cinquante pages, des catalogues qui changent chaque semaine. Le web scraping, c’est l’art de transformer ces pages en données exploitables — un tableau qu’on trie, une base qu’on interroge, un fichier qu’on compare d’un mois à l’autre. En Python, trois outils dominent le domaine, et la première compétence à acquérir n’est pas de les maîtriser tous, mais de savoir lequel sortir pour quel travail.

Ce guide est la carte du territoire. Il pose les concepts (comment une page arrive jusqu’à vous, pourquoi certaines résistent), tranche le choix entre BeautifulSoup, Scrapy et Playwright, et vous oriente vers six tutoriels pratiques qui construisent, brique par brique, un véritable outil de veille. Au bout du parcours, vous ne saurez pas seulement scraper : vous saurez le faire proprement, à l’échelle, et de façon responsable.

🎯 Ce que ce parcours vous permettra de faire

  • Décider, face à n’importe quel site, quel outil Python employer — et pourquoi.
  • Extraire des données d’une page statique avec requests et BeautifulSoup, puis les nettoyer et les stocker.
  • Industrialiser une collecte sur un site entier avec Scrapy : pagination, cadence maîtrisée, pipelines de traitement.
  • Récupérer du contenu généré en JavaScript en pilotant un vrai navigateur avec Playwright.
  • Scraper de façon responsable et légale : robots.txt, limites de cadence, données personnelles, conditions d’utilisation.

🗺️ Le parcours d’apprentissage

Les six tutoriels se suivent dans un ordre pensé pour monter en puissance, autour d’un projet fil rouge unique : « VeilleManuels », l’outil d’une libraire de Dakar, Aminata, qui veut suivre les prix et la disponibilité du catalogue en ligne de son grossiste. Chaque tutoriel ajoute une brique réelle à ce projet.

  1. Extraire une page — on télécharge et on lit une page de catalogue avec requests et BeautifulSoup.
  2. Couvrir tout le catalogue et nettoyerpagination, nettoyage et export en CSV et SQLite.
  3. Passer au frameworkcréer un spider Scrapy structuré.
  4. IndustrialiserScrapy avancé : throttling et pipelines.
  5. Franchir le mur du JavaScriptscraper les pages dynamiques avec Playwright.
  6. Scraper en professionnelle scraping responsable : robots.txt, éthique et limites.

Vous pouvez suivre ce parcours du début à la fin, ou piocher le tutoriel qui répond à votre besoin du moment. Ce guide, lui, reste votre point de repère pour comprendre comment les pièces s’emboîtent.

Pourquoi le web scraping est utile aujourd’hui

Le réflexe d’un développeur devrait toujours être de chercher d’abord une API officielle : une porte d’entrée prévue pour les programmes, propre et autorisée. Mais cette porte n’existe pas toujours. Une mairie publie ses délibérations en HTML sans interface dédiée ; un grossiste affiche son catalogue sur un site vitrine ; une administration met ses statistiques dans des tableaux web. Dans tous ces cas, l’information est publique et accessible, mais pas exploitable par programme — sauf à la scraper.

Les usages légitimes ne manquent pas : veille tarifaire pour une PME, agrégation d’offres d’emploi, suivi de prix de denrées sur des marchés en ligne, constitution de jeux de données pour la recherche ou l’apprentissage automatique, archivage de contenus publics. Le point commun de ces cas honnêtes : on collecte des faits publiquement affichés, à un rythme raisonnable, pour en faire un usage qui ne nuit à personne. C’est ce cadre que ce parcours adopte de bout en bout — et le dernier tutoriel y est entièrement consacré, car la capacité technique ne dispense jamais du jugement.

Les concepts fondamentaux

Pourquoi Python pour le scraping ?

Le scraping existe dans tous les langages, mais Python s’y est imposé pour une raison simple : son écosystème couvre toute la chaîne sans rupture. Les trois meilleurs outils du domaine — BeautifulSoup, Scrapy, Playwright — y sont matures et bien documentés. La même langue sert ensuite à nettoyer les données (pandas), à les stocker (SQLite, intégré au langage) et à les analyser, sans jamais changer d’environnement. À cela s’ajoute une syntaxe lisible qui rend le code de scraping facile à écrire, à relire et à réparer — un atout réel le jour où un site change sa structure et qu’il faut ajuster vite. Pour qui débute, c’est aussi le langage le plus enseigné et le mieux entouré de ressources francophones.

Comment une page web arrive jusqu’à vous

Quand votre navigateur affiche une page, il s’est passé deux choses. D’abord, il a envoyé une requête HTTP à un serveur, qui a renvoyé un document HTML — du texte balisé décrivant le contenu et sa structure. Ensuite, le navigateur a interprété ce HTML (et parfois exécuté du JavaScript) pour en faire la page visuelle que vous voyez. Un scraper rejoue la première étape par programme : il récupère le HTML. Tout le travail consiste ensuite à y retrouver les morceaux qui vous intéressent.

Les deux temps de tout scraping : récupérer, puis extraire

C’est la distinction la plus utile à garder en tête. Récupérer, c’est obtenir le HTML d’une page — le rôle de requests, ou du moteur réseau de Scrapy, ou du navigateur de Playwright. Extraire, c’est isoler les données dans ce HTML — le rôle de BeautifulSoup, ou des sélecteurs de Scrapy, ou des locators de Playwright. Presque tous les outils se rangent dans l’une ou l’autre de ces cases, et beaucoup se combinent (récupérer avec Playwright, extraire avec BeautifulSoup, par exemple).

La grande bifurcation : statique ou dynamique

C’est la question qui détermine votre outil. Une page est statique quand le serveur renvoie directement le contenu dans le HTML : les données sont là, dans le document reçu. Une page est dynamique quand le serveur renvoie un squelette presque vide, et que c’est du JavaScript, exécuté dans le navigateur, qui va chercher les données et les insère ensuite. Sur une page statique, requests suffit. Sur une page dynamique, requests ne voit que le squelette — il faut un outil qui exécute le JavaScript, comme Playwright. Le test est simple : si « Afficher le code source » dans votre navigateur montre déjà la donnée, c’est statique ; sinon, c’est dynamique.

Extraire, crawler, automatiser un navigateur

Trois échelles d’ambition, trois familles d’outils. Extraire une ou quelques pages connues d’avance : un script requests + BeautifulSoup fait l’affaire. Crawler, c’est parcourir un site en suivant ses liens, à grande échelle, avec gestion des erreurs, de la cadence et de la reprise : c’est le terrain de Scrapy. Automatiser un navigateur, c’est piloter un vrai Chrome pour franchir l’obstacle du JavaScript ou simuler des interactions (clics, défilement) : c’est Playwright. Ces familles ne s’opposent pas, elles se complètent selon le besoin.

Les sélecteurs CSS : la compétence qui sert partout

Quel que soit l’outil, extraire une donnée revient toujours à désigner un élément dans la page. Le langage universel pour ça, c’est le sélecteur CSS — le même qui sert à mettre en forme les pages. BeautifulSoup, Scrapy et Playwright le comprennent tous, ce qui fait du sélecteur la compétence la plus rentable du domaine : apprise une fois, elle resservira partout.

Le principe tient en quelques règles. article vise toutes les balises de ce nom ; .prix vise les éléments portant la classe « prix » ; #total vise l’élément d’identifiant « total » ; article.product combine balise et classe ; div p vise les paragraphes situés à l’intérieur d’un div. On les repère directement dans le navigateur : un clic droit sur l’élément voulu, puis « Inspecter », ouvre le HTML et révèle ses classes. Maîtriser cette poignée de motifs, c’est tenir la clé de la plus grande partie du travail d’extraction — le reste n’est que de la plomberie autour.

De la page à la décision : la chaîne complète

Un scraper n’est jamais une fin en soi ; il est le premier maillon d’une chaîne qui mène à une décision. Cette chaîne comporte quatre temps qu’il vaut la peine de distinguer, car chacun a ses outils et ses pièges. Récupérer le HTML (requests, Scrapy ou Playwright). Extraire les données utiles (les sélecteurs). Nettoyer : convertir les prix en nombres, retirer les doublons, écarter les lignes incomplètes — l’étape la plus négligée, et pourtant celle qui sépare une donnée exploitable d’un tas inutilisable. Stocker enfin, dans un CSV pour le partage ou une base pour l’historique et l’analyse.

Ce parcours suit cette chaîne dans l’ordre, et c’est volontaire : beaucoup de débutants s’arrêtent au deuxième maillon, fiers d’avoir « récupéré quelque chose », sans voir que la valeur naît des deux derniers. Aminata ne veut pas les pages du grossiste ; elle veut savoir quels manuels ont augmenté depuis la semaine dernière. Entre les deux, il y a toute la chaîne — et ce guide la parcourt en entier.

Choisir le bon outil : BeautifulSoup, Scrapy ou Playwright

Voici le cœur de ce guide — la table de décision qui vous évitera de sortir un bazooka pour écraser une mouche, ou l’inverse. Lisez-la comme une suite de questions : la page est-elle dynamique ? le travail est-il ponctuel ou récurrent ? une page ou tout un site ?

Votre besoin Outil recommandé Pourquoi
Quelques pages statiques, extraction ponctuelle requests + BeautifulSoup Simple, léger, rien à configurer ; idéal pour apprendre et pour les petits besoins
Un site entier à crawler, collecte récurrente Scrapy Framework complet : pagination, cadence, pipelines, export, reprise — tout est géré
Contenu chargé en JavaScript (page dynamique) Playwright Pilote un vrai navigateur qui exécute le JavaScript et révèle le contenu
Page dynamique ET volumineuse Playwright + BeautifulSoup Playwright pour obtenir le HTML rendu, BeautifulSoup pour l’extraction confortable
Données disponibles via une API officielle Aucun scraping Toujours préférer l’API : plus stable, plus rapide, sans zone grise

Une règle d’or se dégage de ce tableau : on commence toujours par l’outil le plus simple qui résout le problème. requests est plus léger que Scrapy, qui est plus léger qu’un navigateur piloté. Un débutant qui dégaine Playwright pour une page statique se complique la vie sans raison ; un développeur qui s’entête en requests sur une page dynamique perd son temps. Le bon choix vient de la compréhension du terrain, pas de l’habitude.

Vue d’ensemble pratique : les briques du projet

Le parcours construit « VeilleManuels » en six briques qui correspondent aux six tutoriels. Voici comment elles s’assemblent.

Brique 1 — l’extraction de base. On apprend à télécharger une page proprement (avec un en-tête d’identification, un délai d’attente, une vérification du statut) et à en extraire titre, prix et disponibilité avec les sélecteurs CSS de BeautifulSoup. C’est le geste fondateur, détaillé dans le premier tutoriel.

Brique 2 — la couverture et la qualité. Une page ne suffit pas : on suit la pagination pour couvrir tout le catalogue, puis on transforme les données brutes en données fiables avec pandas (typage, doublons, valeurs manquantes) avant de les exporter en CSV et de les historiser en SQLite. C’est l’objet du tutoriel sur la pagination et le nettoyage.

Brique 3 — le passage au framework. Quand le script artisanal montre ses limites, on reconstruit le projet en Scrapy : une structure claire, un spider qui déclare ses cibles, des sélecteurs mis au point dans un shell interactif, une sortie structurée. Tout est dans le tutoriel sur la création d’un spider.

Brique 4 — l’industrialisation. On fait crawler le site entier sans le surcharger (délai et AutoThrottle), on nettoie et déduplique dans des pipelines, et on exporte automatiquement. Le tutoriel Scrapy avancé détaille cette montée en charge.

Brique 5 — le contenu dynamique. Lorsque le fournisseur lance un portail dont les données arrivent en JavaScript, requests devient aveugle. On pilote alors un vrai navigateur avec Playwright : on attend l’apparition du contenu, on l’extrait, on gère le défilement infini. C’est le sujet du tutoriel Playwright.

Brique 6 — la responsabilité. Enfin, on entoure tout cela des bonnes pratiques qui font durer un scraper : lire robots.txt, s’identifier, limiter sa cadence, respecter les données personnelles et le droit. C’est le tutoriel sur le scraping responsable, à lire absolument avant de viser un vrai site.

Tutoriels du parcours

Chaque tutoriel ci-dessous construit une brique de « VeilleManuels » et peut aussi se suivre seul :

Le cadre légal et éthique, en bref

Pouvoir scraper ne signifie pas avoir le droit de tout scraper. Trois repères valent d’être posés dès maintenant, même si le dernier tutoriel les développe. D’abord, le fichier robots.txt exprime la volonté du site sur ce que les robots peuvent visiter : c’est un standard reconnu (RFC 9309) qu’on respecte par principe. Ensuite, les conditions d’utilisation d’un site ont une valeur contractuelle et peuvent interdire l’extraction automatisée. Enfin, les données personnelles relèvent de lois strictes — la loi sénégalaise sur la protection des données et sa Commission (la CDP), le RGPD en Europe — qui interdisent de les collecter sans base légale. La zone clairement défendable : des faits publics, à cadence raisonnable, sans données personnelles, en respectant robots.txt et les conditions du site. C’est exactement le périmètre du projet fil rouge de ce parcours.

Adaptation au contexte ouest-africain

Scraper depuis Dakar, Cotonou ou Niamey impose des contraintes que les tutoriels occidentaux ignorent souvent, et ce parcours en tient compte de bout en bout. La bande passante d’abord : quand la connexion est facturée au mégaoctet, télécharger cent fois la même page pour mettre au point ses sélecteurs coûte cher. Le réflexe, répété dans plusieurs tutoriels, est d’enregistrer une page en local ou d’utiliser un cache (requests-cache, le cache HTTP de Scrapy) pour travailler hors ligne et n’envoyer une vraie requête que lorsque c’est nécessaire.

La puissance machine ensuite : sur un poste modeste ou un petit VPS, un navigateur piloté par Playwright pèse lourd. D’où l’importance de n’y recourir que pour les pages réellement dynamiques, de tourner en mode headless, et de bloquer le chargement des images et des polices pour alléger encore. Les coupures de courant ou de réseau, enfin, rendent indispensable un code résilient : requêtes avec délai d’attente, reprise après erreur, crawls qui peuvent repartir là où ils se sont arrêtés. Côté hébergement, un petit VPS à quelques euros par mois suffit largement à faire tourner une collecte nocturne, et le paiement par mobile money rend ces services accessibles sans carte bancaire internationale. Enfin, le cadre juridique régional se construit : plusieurs pays disposent désormais d’autorités de protection des données, et la Convention de Malabo pose un cadre continental — autant de raisons de garder le réflexe responsable.

Erreurs fréquentes à éviter

Erreur Cause Solution
Sortir Playwright pour une page statique Réflexe « navigateur » au lieu d’analyser la page Tester requests d’abord ; n’utiliser un navigateur que si le contenu est en JavaScript
Scraper trop vite et se faire bloquer Aucun délai entre les requêtes Espacer les requêtes, respecter crawl_delay et le code 429
Construire les URL de pages en dur On suppose un nombre de pages fixe Suivre le lien « suivant » et s’arrêter quand il n’existe plus
Extraire avant la fin du rendu JavaScript Lecture juste après le chargement Attendre un élément précis (wait_for_selector), jamais une durée fixe
Ne pas nettoyer les données On s’arrête à « j’ai récupéré quelque chose » Typer, dédupliquer, gérer les valeurs manquantes avant d’exploiter
Ignorer robots.txt et les conditions d’utilisation On pense que « public » veut dire « libre de tout » Lire robots.txt et les CGU ; éviter les données personnelles
Coder un scraper fragile sans gestion d’erreurs On suppose que le réseau et le HTML sont parfaits Prévoir délais, réessais, et sélecteurs vérifiés dans un shell

FAQ

Faut-il apprendre les trois outils ?
Pas forcément, mais comprendre leurs rôles, oui. requests + BeautifulSoup est le socle incontournable. Scrapy devient utile dès qu’on crawle un site entier de façon récurrente. Playwright n’est nécessaire que pour le contenu en JavaScript. Commencez par le premier ; ajoutez les autres quand le besoin se présente.

Le web scraping est-il légal ?
Il n’y a pas de réponse unique. Extraire des faits publics, à cadence raisonnable, sans données personnelles et en respectant robots.txt et les conditions d’utilisation, est généralement défendable. Mais la nature des données et l’usage prévu changent tout. Le tutoriel dédié détaille ces limites.

Quelle version de Python utiliser ?
Python 3.13 est le bon choix pour ce parcours : il est stable et compatible avec les trois outils, y compris Playwright, qui ne prend pas encore en charge la toute dernière version du langage au moment d’écrire.

Scrapy ou BeautifulSoup pour débuter ?
BeautifulSoup, sans hésiter. Il fait comprendre les mécanismes de base (récupérer, sélectionner, extraire) sans la structure d’un framework. Scrapy prend tout son sens ensuite, quand on industrialise.

Comment savoir si une page est dynamique ?
Ouvrez « Afficher le code source » dans votre navigateur (ou testez avec requests). Si la donnée recherchée y figure, la page est statique. Si elle est absente — chargée seulement à l’affichage — la page est dynamique et demande Playwright.

Et si le site propose une API ?
Utilisez-la. Une API officielle est toujours préférable au scraping : elle est conçue pour l’accès programmatique, plus stable dans le temps, plus rapide, et sans ambiguïté juridique. Le scraping est la solution quand l’API n’existe pas.

Pour aller plus loin

Partager