De quelles specs VPS ai-je besoin pour le web scraping ?

Ça dépend de la stack. Un scraper HTTP simple (httpx/requests tapant des API ou du HTML statique) est léger — un Nano à 3 $ avec 1 Go suffit largement. Dès que vous avez besoin d'un vrai navigateur pour des sites lourds en JavaScript, Playwright avec Chromium headless veut 2 à 4 Go : un Micro à 5 $ pour un ou deux contextes de navigateur, un Small à 8 $ si vous en faites tourner plusieurs en parallèle. Chromium est le glouton de RAM, pas votre code.

Puis-je scraper depuis l'IP propre du serveur, ou me faut-il des proxys ?

Pour du scraping à faible volume et bien élevé de sites qui l'autorisent, l'IP du serveur suffit. À grande échelle, ou contre des sites qui limitent par IP, il vous faudra un pool de proxys externes — une IP (partagée ou dédiée) ne peut pas répartir la charge, et marteler depuis une seule adresse la fait bloquer vite. Une IP dédiée vous donne une réputation propre que vous contrôlez ; les proxys vous en donnent plusieurs.

cron ou timer systemd pour les scrapes planifiés ?

Un timer systemd, dans presque tous les cas. Contrairement à cron, il vous donne une vraie journalisation via journalctl, l'ordonnancement des dépendances, le rattrapage automatique si la machine était éteinte, et un statut par exécution que vous pouvez inspecter. cron marche encore pour les jobs ultra-simples, mais un timer est le meilleur choix par défaut sur un serveur que vous maintenez vraiment.

Le web scraping est-il autorisé sur le VPS ?

Le scraping légal et respectueux — oui. Le scraping agressif qui ignore les limites de débit ou le robots.txt, ou qui revient à marteler une cible jusqu'au déni de service, est une violation de l'usage acceptable et fait résilier le service. Scrapez ce que vous avez le droit de scraper, bridez-vous, et ne transformez pas un scraper en attaque.

VPS pour le web scraping : installation, dimensionnement et limites honnêtes

Un scraper sur votre portable, c'est bien jusqu'à ce que vous le fermiez en pleine exécution, que votre IP domestique soit limitée en débit, ou que vous vouliez que le même job tourne toutes les heures, que vous soyez éveillé ou non. Le déplacer vers un VPS corrige les trois : il reste en marche 24/7, il ne crame pas la réputation de votre IP domestique, et cron ou un timer systemd le lance à l'heure sans vous. Voici comment mettre ça en place, quelle taille de serveur il vous faut vraiment, et les parties que la plupart des guides sautent discrètement.

Pourquoi un VPS bat votre machine pour ça

24/7 et planifié. Un scraper qui tourne toutes les heures a besoin d'un hôte toujours en marche. Un portable ne l'est pas.
Votre IP domestique reste propre. Scraper depuis chez vous, c'est votre IP résidentielle qui encaisse les limites de débit et les blocages. Faites-le depuis un serveur et votre propre connexion reste intacte.
Stabilité. Pas de mise en veille, pas de coupures wifi en plein crawl, une connexion de datacenter stable, et un endroit où accumuler les résultats.

La stack, et ce dont chaque partie a besoin

Deux catégories de poids très différentes, et choisir le mauvais plan gaspille de l'argent ou affame le job :

httpx / requests (Python) — pour les API, les endpoints JSON et le HTML statique. C'est léger : le processus tient dans des dizaines de mégaoctets, limité par le réseau, pas par le CPU. Un Nano à 3 $ (1 vCPU / 1 Go) fait tourner ça confortablement, même avec de la concurrence via asyncio.
Playwright / Chromium headless — pour les sites rendus en JavaScript où il vous faut un vrai navigateur. C'est le lourd. Chromium headless fait environ 300 à 400 Mo par instance de navigateur, plus 100 à 200 Mo par contexte/onglet ouvert, plus votre runtime. Budget :
- Micro à 5 $ (2 vCPU / 2 Go) — un ou deux contextes de navigateur à la fois.
- Small à 8 $ (4 vCPU / 4 Go) — plusieurs contextes en parallèle, ou des pages plus lourdes.

La règle : votre code n'est presque jamais le goulot d'étranglement — Chromium l'est. Dimensionnez pour le navigateur, pas pour le scraper.

Planification : timer systemd plutôt que cron

cron marche, mais un timer systemd est le meilleur choix par défaut sur un serveur que vous maintenez : logs via journalctl, rattrapage si la machine était éteinte, et statut par exécution inspectable. Une configuration minimale :

# /etc/systemd/system/scrape.service
[Unit]
Description=Run scraper
[Service]
Type=oneshot
User=scraper
WorkingDirectory=/home/scraper/job
ExecStart=/home/scraper/job/venv/bin/python scrape.py

# /etc/systemd/system/scrape.timer
[Unit]
Description=Hourly scrape
[Timer]
OnCalendar=hourly
Persistent=true
[Install]
WantedBy=timers.target

sudo systemctl enable --now scrape.timer
journalctl -u scrape.service -f   # observer les exécutions

Persistent=true est le truc que cron ne peut pas faire : si le serveur était éteint à l'heure prévue, le job se déclenche une fois au boot au lieu de sauter silencieusement.

Où vont les résultats

Restez simple et adaptez au volume : SQLite pour des données structurées que vous interrogerez (un fichier, zéro installation), CSV pour des vidages tabulaires rapides, ou un stockage objet compatible S3 quand les résultats dépassent la machine ou que vous les voulez hors serveur. Faites tourner vos logs (logrotate ou limites journald) pour qu'un scraper bavard ne remplisse pas lentement le disque.

La partie honnête : IP de sortie et réputation

C'est le détail qui décide si votre scraper marche une semaine ou se fait bloquer dès le premier jour.

Sur un plan NAT, le trafic sortant partage une IP de sortie avec d'autres clients. La réputation de cette IP est partagée — un voisin qui scrape la même cible peut faire limiter l'adresse avant que vous n'envoyiez une seule requête. Bien pour du scraping léger et occasionnel ; un risque à grand volume.

Une IP dédiée vous donne votre propre réputation de sortie — le comportement de personne d'autre ne l'affecte. Mais ça coupe dans les deux sens : le scraping agressif crame votre propre IP propre, et une fois qu'une cible la bloque, elle est bloquée. Une IP dédiée, c'est du contrôle, pas de l'immunité.

À grande échelle réelle, il vous faut des pools de proxys externes. Aucune IP unique — partagée ou dédiée — ne peut répartir la charge sur beaucoup d'adresses, ce qu'exige le scraping sérieux contre des cibles limitées par IP. Les proxys sont une couche générique tierce que vous ajoutez par-dessus ; le VPS fait tourner le scraper, le pool de proxys fournit les adresses. N'attendez pas d'une IP de serveur qu'elle fasse le boulot d'un pool de proxys.

Éthique et l'AUP — pas optionnel

Le scraping vit dans une zone grise légale et éthique, alors soyez lucide :

Respectez les limites de débit et le robots.txt. Bridez vos requêtes. Un scraper poli ressemble à du trafic ; un impoli ressemble à une attaque.
Ne faites pas de DoS sur votre cible. Marteler un site jusqu'à ce qu'il tombe n'est pas du scraping, c'est un déni de service — et c'est une violation de l'usage acceptable ici qui fait résilier le service.
Ne scrapez que ce que vous avez le droit. La collecte de données légale et autorisée est la ligne. Franchissez-la et c'est sur vous.

Le bilan

Un VPS est le bon foyer pour un scraper : toujours en marche, planifié, et hors de votre IP domestique. Adaptez le plan à la stack — Nano à 3 $ pour httpx, Micro à 5 $ à Small à 8 $ pour Playwright — planifiez avec un timer systemd, et soyez honnête sur les IP : une sortie partagée partage sa réputation, une IP dédiée est la vôtre à bâtir ou à cramer, et la vraie échelle veut dire des pools de proxys. Verrouillez d'abord la machine avec la checklist de sécurité pour nouveau VPS, dimensionnez-la bien avec le guide de dimensionnement VPS, et si la confidentialité du paiement sans carte compte, l'analyse du VPS anonyme est la version honnête. Scrapez de manière responsable — l'AUP est réelle.

Prêt à scraper ? Un plan Micro est un bon départ ; les grands crawls concurrents s'en sortent mieux sur Small.