Google Colab et Jupyter Notebook sont des outils pratiques pour écrire et exécuter rapidement des scripts de scraping sans installer Python sur votre machine locale. Mais les notebooks cloud ont une particularité souvent oubliée : toutes les requêtes proviennent des adresses IP des centres de données de Google, qui sont depuis longtemps connues des systèmes anti-bot et sont bannies presque instantanément. Dans cet article, nous allons voir comment connecter correctement un proxy dans Colab et Jupyter, quelles limitations impose l'environnement cloud et comment structurer le scraping pour qu'il ne tombe pas après les 50 premières requêtes.
Pourquoi Google Colab est plus souvent banni qu'un PC ordinaire
Le principal problème de Colab pour le scraping est le pool commun d'adresses IP. Chaque fois que vous lancez un notebook, Google attribue une machine virtuelle avec une IP de ses plages cloud (AS15169 et similaires). Ces plages sont depuis longtemps sur les listes noires de la plupart des systèmes anti-bot : Cloudflare, DataDome, PerimeterX, ainsi que la protection intégrée de Wildberries, Ozon et des marketplaces les reconnaissent en quelques fractions de seconde. La requête n'atteint même pas le site — elle est filtrée par ASN (Autonomous System Number) avant même de vérifier le User-Agent ou le comportement.
La deuxième raison est la popularité de l'utilisation. Des milliers de développeurs exécutent simultanément des scrapers, des bots et des scripts ML via Colab, donc la réputation de ces IP auprès de nombreux sites cibles est déjà "brûlée" bien avant votre requête. Même si vous effectuez une requête GET soignée toutes les 10 secondes, le site peut retourner un 403 simplement parce que quelqu'un a bombardé le serveur avec 500 threads une heure auparavant depuis la même plage.
La troisième raison est que Jupyter, lorsqu'il est exécuté localement, n'a généralement pas ce problème (si vous avez une IP domestique ou de bureau ordinaire), mais dès que vous commencez à travailler via JupyterHub sur un serveur d'hébergement ou dans un conteneur d'un fournisseur cloud — la situation devient la même que dans Colab. Par conséquent, la question "les proxies sont-ils nécessaires ou non" pour les notebooks cloud se résout sans équivoque : sans eux, le scraping ne fonctionne pratiquement pas au-delà des premières requêtes.
Quel type de proxy convient au scraping cloud
Le choix du type de proxy dépend de ce que vous scrapez et de l'agressivité de la protection du site cible. Pour Colab et Jupyter, il est également important de prendre en compte un autre aspect : la session du notebook est limitée dans le temps, donc les sessions sticky à long terme des proxies ne sont pas toujours critiques — ce qui est souvent important, c'est la stabilité de la connexion dans le cadre d'un seul lancement.
| Type de proxy | Quand utiliser dans Colab/Jupyter | Caractéristiques |
|---|---|---|
| Proxies de centres de données | Scraping de sites sans protection stricte, API ouvertes, pages statiques | Haute vitesse, faible coût, mais peuvent également être bannis par ASN sur des sites agressifs |
| Proxies résidentiels | Scraping de Wildberries, Ozon, Avito, Google, réseaux sociaux avec protection anti-bot | IP d'utilisateurs réels, rarement sur les listes noires, latence plus élevée |
| Proxies mobiles | Scraping des versions mobiles des sites, TikTok, Instagram via API | Le plus haut niveau de confiance, mais plus cher et rotation plus lente |
Pour la plupart des tâches de scraping sur des marketplaces et des moteurs de recherche depuis Colab, le meilleur équilibre sera une combinaison de proxies résidentiels avec rotation à chaque requête — cela réduit la probabilité de bannissement par le comportement, même si la requête elle-même est exécutée depuis l'environnement cloud de Google.
Configuration des proxies dans requests et urllib
La configuration de base des proxies dans Colab n'est pas différente de celle d'un environnement Python local. La seule différence est que dans Colab, les bibliothèques doivent généralement être installées via !pip install, car l'image standard ne contient pas toujours tout le nécessaire.
!pip install requests
import requests
proxy = {
"http": "http://login:[email protected]:9000",
"https": "http://login:[email protected]:9000"
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}
response = requests.get(
"https://example.com/catalog",
proxies=proxy,
headers=headers,
timeout=15
)
print(response.status_code)
print(response.text[:500])
Un point important : dans Colab, il n'y a pas de fichier de configuration permanent, donc le login et le mot de passe du proxy doivent soit être codés en dur (ce qui n'est pas sûr lors de la publication du notebook), soit être stockés dans des variables d'environnement Colab via google.colab.userdata, soit être connectés via Colab Secrets. C'est plus pratique que de stocker le mot de passe directement dans le code, surtout si vous partagez le notebook avec des collègues.
from google.colab import userdata
proxy_login = userdata.get('PROXY_LOGIN')
proxy_pass = userdata.get('PROXY_PASS')
proxy_url = f"http://{proxy_login}:{proxy_pass}@gate.proxycove.com:9000"
proxies = {"http": proxy_url, "https": proxy_url}
Proxy avec Selenium et Chrome headless dans Colab
Si le site rend le contenu via JavaScript (situation typique pour Wildberries, Ozon, Avito), un simple requests ne suffit pas — un navigateur headless est nécessaire. Dans Colab, cela se fait généralement avec Selenium et Chromium, qui doivent être installés manuellement, car ils ne sont pas présents dans l'image de base.
!apt-get update
!apt install chromium-chromedriver
!pip install selenium
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
chrome_options = Options()
chrome_options.add_argument('--headless')
chrome_options.add_argument('--no-sandbox')
chrome_options.add_argument('--disable-dev-shm-usage')
chrome_options.add_argument('--proxy-server=http://gate.proxycove.com:9000')
driver = webdriver.Chrome(options=chrome_options)
driver.get("https://example.com/catalog")
print(driver.page_source[:500])
driver.quit()
Le problème est que le drapeau --proxy-server ne prend pas en charge l'authentification avec un login et un mot de passe directement. Pour les proxies avec authentification dans Selenium, il faut soit utiliser l'authentification par IP (whitelisting par l'IP statique du notebook, ce qui est instable dans Colab, car l'IP de la machine change à chaque nouveau lancement), soit générer une extension Chrome "à la volée" avec les informations d'identification du proxy, soit utiliser un tunnel proxy via une bibliothèque comme selenium-wire, qui prend en charge les proxies authentifiés par défaut.
!pip install selenium-wire
from seleniumwire import webdriver
proxy_options = {
'proxy': {
'http': 'http://login:[email protected]:9000',
'https': 'http://login:[email protected]:9000',
}
}
driver = webdriver.Chrome(seleniumwire_options=proxy_options, options=chrome_options)
driver.get("https://example.com/catalog")
Jupyter Notebook : local vs cloud
Jupyter Notebook, exécuté sur une machine locale (via Anaconda ou directement via pip), utilise votre adresse IP domestique ou de bureau — et dans ce cas, les proxies ne sont nécessaires que pour masquer ou contourner les restrictions géographiques, et non pour éviter le bannissement par ASN du centre de données. La configuration est alors entièrement identique à celle d'un script Python ordinaire : même requests, même Selenium, sans limitations sur l'installation des pilotes et des paquets système.
La situation change si vous utilisez Jupyter via un service cloud : JupyterHub sur VPS, Kaggle Notebooks, Deepnote, Binder ou un cluster cloud d'entreprise. Dans ces cas, l'IP appartient à nouveau au centre de données du fournisseur, et tous les problèmes de Colab sont pertinents un à un. La principale différence avec Colab est que ces services ont souvent une IP plus stable pendant la session (ne change pas à chaque redémarrage du noyau), ce qui facilite la configuration du whitelisting par IP, si votre fournisseur de proxy le prend en charge.
Conclusion pratique : si le scraping est critique pour l'entreprise (par exemple, le suivi quotidien des prix des concurrents sur les marketplaces), il est préférable de ne pas s'attacher aux notebooks cloud gratuits comme environnement de production, mais de les utiliser uniquement pour le développement et le test du script, en transférant le scraper final sur un serveur avec une IP permanente et des proxies configurés.
Limitations des notebooks cloud qui cassent le scraping
En plus des problèmes de réputation des IP, Google Colab a un certain nombre de limitations techniques qui affectent directement la stabilité du scraping :
- Délai d'inactivité. La version gratuite de Colab déconnecte le notebook après ~90 minutes d'inactivité et termine la session après 12 heures de fonctionnement continu — le scraping de milliers de pages doit être divisé en parties ou sauvegarder les résultats intermédiaires sur Google Drive.
- Changement d'IP à chaque nouveau runtime. Si vous déconnectez et reconnectez l'environnement d'exécution, l'adresse IP de la machine virtuelle change — cela casse toute configuration de whitelisting par IP du côté du service proxy.
- Limitation des connexions sortantes. Google limite le nombre de connexions réseau simultanées à partir d'une seule machine virtuelle, donc une multithreading agressive avec des dizaines de requêtes parallèles peut être limitée non pas par le blocage du site, mais par les limites de Colab lui-même.
- Pas de stockage persistant sans montage de disque. Les cookies, les sessions de navigateur et le cache des connexions proxy disparaissent à chaque redémarrage — pour le scraping avec authentification, il est nécessaire de sauvegarder explicitement les cookies dans un fichier sur Google Drive.
- Retards réseau imprévisibles. L'infrastructure cloud de Google peut parfois donner des pics de latence, ce qui nécessite de définir des délais d'attente pour les requêtes avec une marge (15-30 secondes au lieu des 5-10 secondes standard).
Ces limitations font de Colab un excellent outil pour le développement et le débogage de la logique du scraper, mais mal adapté aux tâches de production à long terme — pour celles-ci, il est préférable de transférer le script prêt sur un VPS ou un serveur dédié avec une IP propre.
Rotation des proxies et gestion des erreurs en boucle
Pour que le scraping ne tombe pas au premier blocage, le code doit inclure une logique de tentatives répétées avec remplacement des proxies. Voici un exemple d'une simple boucle avec rotation et gestion des erreurs, qui peut être exécutée directement dans Colab.
import requests
import time
import random
proxy_pool = [
"http://login:[email protected]:9000",
"http://login:[email protected]:9001",
"http://login:[email protected]:9002",
]
def get_with_retry(url, max_retries=5):
for attempt in range(max_retries):
proxy_url = random.choice(proxy_pool)
proxies = {"http": proxy_url, "https": proxy_url}
try:
response = requests.get(url, proxies=proxies, timeout=20)
if response.status_code == 200:
return response
else:
print(f"Tentative {attempt+1} : statut {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"Tentative {attempt+1} : erreur {e}")
time.sleep(random.uniform(2, 5))
return None
result = get_with_retry("https://example.com/catalog")
if result:
print(result.status_code)
else:
print("Toutes les tentatives ont échoué")
Pour le scraping de grands catalogues (par exemple, des milliers de fiches produits sur Wildberries), cette logique est souvent enveloppée dans une file d'attente de tâches avec des pauses entre les requêtes et la sauvegarde des résultats intermédiaires en CSV ou dans une base de données directement sur Google Drive, afin de ne pas perdre de progrès en cas d'interruption de la session Colab.
Checklist avant de lancer le scraper dans Colab
- Les proxies sont connectés et testés avec une requête de test distincte avant la boucle principale
- Le login et le mot de passe du proxy sont stockés dans Colab Secrets, et non dans le code ouvert
- Pour les sites JS, Selenium est utilisé avec selenium-wire ou une extension d'authentification définie
- Le code contient une logique de retry et une rotation des proxies en cas d'erreurs 403/429
- Les résultats intermédiaires sont sauvegardés sur Google Drive toutes les N entrées
- Les délais d'attente des requêtes sont augmentés en tenant compte des éventuels retards du réseau cloud
- La parallélisation des requêtes est limitée pour ne pas atteindre les limites des connexions sortantes de Colab
- Pour les tâches de production, le script doit être transféré sur un serveur distinct avec une IP permanente
Conclusion
Google Colab et Jupyter cloud sont excellents pour le développement rapide et le test de la logique du scraper, mais en raison des IP communes des centres de données, ils nécessitent presque toujours des proxies dès les premières étapes. Pour des sites simples sans protection agressive, des proxies de centres de données suffisent, tandis que pour le scraping de marketplaces, de moteurs de recherche et de réseaux sociaux, des IP résidentielles et mobiles fonctionnent de manière plus fiable, car elles sont moins souvent filtrées par ASN.
Si vous prévoyez un suivi régulier des prix sur Wildberries ou Ozon directement depuis Colab, nous vous recommandons de commencer avec des proxies résidentiels — ils offrent un accès stable sans blocages fréquents, et pour des scripts de test ponctuels, vous pouvez vous contenter de proxies de centres de données plus économiques, en les connectant de la même manière via requests ou Selenium.