Comment scraper des sites qui exigent une connexion : sessions, cookies et proxys sticky à l'échelle

Une grande partie des données qui valent la peine d’être collectées se trouve derrière une connexion, et les scraper est une discipline différente du scraping de pages publiques. À l’instant où vous vous authentifiez, vous cessez d’être un visiteur anonyme et commencez à opérer un compte, et les comptes se font limiter en débit, défier et bannir de façons que les requêtes anonymes ne connaissent jamais. Tout le jeu passe de « tournez librement pour qu’aucune identité ne se distingue » à « gardez une identité stable pour que le compte ressemble à un vrai utilisateur cohérent ».

Une réserve avant le comment : ne scrapez que des données que vous êtes autorisé à accéder, vos propres comptes, les données d’un partenaire que vous avez la permission d’extraire, une API que vous avez le droit d’utiliser. Les données connectées sont une catégorie légale et éthique différente des données publiques, et savoir si le scraping est légal dépend fortement de cette ligne. Ce guide suppose que vous êtes du bon côté de celle-ci.

Le scraping public tourne. Le scraping authentifié reste cohérent.

L’instinct du scraping public est de tout faire tourner, une IP neuve par requête empêche une seule identité de se distinguer. Derrière une connexion, cet instinct est exactement à l’envers. Vous avez maintenant une identité persistante, le compte, et la cohérence est ce qui le fait paraître légitime. Un compte qui se connecte depuis cinquante pays en une heure, ou saute d’IP en milieu de session, ne ressemble pas à un utilisateur avancé. Il ressemble à un compte compromis, et c’est ce qui déclenche un verrouillage.

Donc le scraping authentifié se ramène à deux choses bien faites : gérer la session pour rester connecté efficacement, et épingler chaque compte à une identité stable et propre pour qu’il n’ait jamais l’air de s’être téléporté.

Gérer la session

Quand vous vous connectez, le serveur vous renvoie un état de session, généralement des cookies, parfois un jeton. La plus grosse erreur, de loin, est de se reconnecter à chaque requête. La ré-authentification est lente, et un déluge de connexions est en soi un drapeau rouge que les endpoints de connexion limitent durement. Connectez-vous une fois, capturez la session, et réutilisez-la.

Avec un client HTTP simple, cela signifie un objet de session persistant qui garde le bocal de cookies et chevauche le proxy :

import requests

proxies = {"https": "http://customer-USER-country-us-sid-acct42-ttl-600:PASS@p.shifter.io:443"}
s = requests.Session()
s.proxies.update(proxies)

# Connectez-vous une fois; la reponse Set-Cookie remplit le bocal.
s.post("https://example.com/login", data={"user": USER, "password": PW})

# Reutilisez la meme session (et la meme IP sticky) pour chaque requete suivante.
r = s.get("https://example.com/account/data")

Au-delà de ça, deux détails comptent. Beaucoup de sites exigent un jeton CSRF ou anti-forgery par session que vous scrapez d’un formulaire ou d’une page précédente et envoyez avec les actions d’écriture, alors lisez-le depuis la session au lieu de le coder en dur. Et beaucoup de sites, après la connexion, exposent une API JSON propre que le frontend du site appelle lui-même ; observer l’onglet réseau la révèle souvent, et frapper cette API authentifiée directement avec vos cookies ou votre jeton capturés est bien plus rapide et léger que de re-rendre des pages.

Épinglez chaque compte à une IP sticky et propre

C’est là que la couche proxy gagne sa place. Un compte devrait présenter un emplacement cohérent, alors chaque compte obtient sa propre session sticky : il sort toujours par la même IP résidentielle pendant la durée de cette session, encodée ici comme le sid dans le nom d’utilisateur. Faire tourner les IP sur un compte connecté est un déclencheur de ban classique, parce que le compte semble sauter entre des emplacements en milieu de session.

Trois choses font tenir l’identité :

• Correspondance géo. L’IP devrait correspondre à là où le compte opère normalement. Un compte américain qui apparaît soudain sur une IP allemande ressemble à un détournement, et beaucoup de sites répondent par une invite de ré-vérification ou un verrouillage.
• Réputation propre. Les endpoints de connexion scrutent la réputation de l’IP plus durement que les pages publiques, parce que c’est là que se produisent les prises de contrôle de compte. Une adresse signalée subit une friction supplémentaire, invites 2FA, CAPTCHA, écrans « confirmez que c’est vous », avant même d’atteindre les données.
• Un compte, une identité. Si vous faites tourner plusieurs comptes, chacun a besoin de sa propre IP sticky, pas d’une partagée. Les comptes qui se connectent tous depuis une seule adresse se retrouvent liés et signalés ensemble. C’est la version à l’échelle des comptes de l’identité à deux couches qu’un navigateur antidétection gère au niveau de l’appareil : compte distinct, IP distincte, et si vous utilisez un navigateur, empreinte distincte.

Passer à de nombreux comptes

Le motif passe à l’échelle en mappant chaque compte à sa propre identité stable et en gardant ce mappage. Pensez à un registre : compte vers sid sticky, compte vers bocal de cookies, et, si vous pilotez un navigateur, compte vers profil de navigateur.

# Une identite durable par compte: meme sid -> meme IP de sortie, bocal propre.
def session_for(account):
    s = requests.Session()
    sid = f"acct-{account['id']}"
    s.proxies.update({
        "https": f"http://{BASE_USER}-country-{account['geo']}-sid-{sid}-ttl-600:{PW}@p.shifter.io:443"
    })
    load_cookies(s, account)     # restaure le bocal persiste, ou connecte-toi s'il est absent
    return s

Ensuite répartissez la charge sur les comptes au lieu de pousser un compte fort, et bornez la concurrence par compte et par cible, puisque chaque compte a sa propre limite de débit. Le principe de répartition de charge s’applique, mais l’unité sur laquelle vous distribuez, ce sont des comptes, chacun sur son identité fixe, pas des IP brutes.

Gérez les modes de défaillance

Trois choses tournent mal, et chacune a une réponse spécifique.

Expiration de session. Les sessions expirent. Détectez-le, une redirection vers la page de connexion, ou un 401, et ré-authentifiez-vous sur la même identité, puis reprenez. La règle critique est de ne pas changer d’IP quand vous vous ré-authentifiez ; une reconnexion depuis un nouvel emplacement est bien plus suspecte que l’expiration elle-même.

Déconnexion silencieuse. Parfois vous obtenez un 200 qui est en réalité la version déconnectée de la page, tout le décor public, rien des données du compte. C’est le cousin authentifié d’un blocage doux : validez que vous êtes toujours connecté en vérifiant un élément que seul un utilisateur connecté voit, au lieu de faire confiance au code de statut. Si le marqueur réservé-au-compte a disparu, ré-authentifiez-vous avant d’enregistrer des lignes vides.

Ré-vérification forcée. Une invite 2FA ou un défi « confirmez que c’est vous » signifie généralement que l’identité a paru risquée, souvent parce que l’IP était signalée ou l’emplacement a changé. Une IP propre, stable et géo-concordante est ce qui garde ceci rare. Quand l’une se déclenche quand même, traitez cette identité comme sous suspicion et reculez au lieu de forcer au travers.

Navigateur ou HTTP pour la connexion elle-même

Ajustez l’outil à la connexion, pas à tout le scrape. Une connexion par formulaire simple qui renvoie des cookies fonctionne bien avec un client HTTP simple, capturez les cookies, réutilisez-les, restez léger. Mais les pages de connexion sont fréquemment la partie la plus défendue d’un site, avec des défis JS, des redirections SSO, des jetons dynamiques et un fingerprinting agressif, précisément parce que c’est là que la fraude se produit. Quand la connexion résiste à un client simple, connectez-vous avec un vrai navigateur (Playwright, Puppeteer ou Selenium), puis soit continuez à le piloter soit exportez les cookies vers un client plus léger pour le gros du travail. C’est aussi là que le fingerprinting TLS et HTTP/2 mord le plus fort, donc l’empreinte réseau d’un vrai navigateur fait souvent la différence à l’étape de connexion même quand le reste du scrape va bien sur un client simple.

Vérifiez avant de faire confiance à une exécution

Après l’authentification, confirmez deux choses : que vous êtes vraiment connecté (récupérez un endpoint réservé-au-compte et vérifiez un marqueur de connexion), et que vous sortez par l’IP sticky que vous attendez (une vérification qui renvoie l’IP devrait donner la même adresse pendant la durée de la session). Si la connexion a « réussi » mais que le marqueur de compte manque, ou que l’IP de sortie dérive entre les requêtes, corrigez-le avant de collecter quoi que ce soit, les deux sont couverts dans les guides de timeout et de détection.

En résumé

Scraper derrière une connexion, c’est une affaire de cohérence d’identité, pas de rotation. Connectez-vous une fois et réutilisez la session au lieu de vous ré-authentifier constamment, épinglez chaque compte à une IP résidentielle sticky, propre et géo-concordante, gardez un compte par identité, ré-authentifiez-vous sur la même identité quand une session expire, et validez que vous êtes toujours connecté au lieu de faire confiance à un 200. Passez à l’échelle en ajoutant des comptes, chacun avec sa propre identité stable, pas en faisant tourner un seul compte entre des adresses.

Réussissez cela et la collecte authentifiée est durable au lieu d’une série de verrouillages. Une IP résidentielle propre et sticky par compte est le fondement sur lequel tout repose, et la tarification au Go vous laisse faire tourner de nombreuses identités de compte stables et ne payer que pour les données que chacune extrait vraiment.