Comment conserver la session, les cookies et les jetons lors de la rotation d'IP : guide pas à pas

Vous avez sûrement déjà vécu ça : le script fonctionne, il vous connecte sur le site, met un article dans le panier, puis l'IP change et soudain le serveur répond comme si vous arriviez pour la première fois. L'utilisateur est déconnecté, le panier est vide, le jeton n'est plus valide. Agaçant ? Carrément. Mais ce problème a une solution d'ingénierie claire, et dans ce guide nous allons la détailler de bout en bout.

Introduction : pourquoi on est déconnecté et le panier se vide après un changement d'IP

Soyons honnêtes : quand la session saute après une rotation d'IP, la première envie est d'accuser le changement d'adresse lui-même. « L'IP a changé, le serveur l'a vu et a tout réinitialisé. » Parfois c'est vrai. Mais bien plus souvent, le problème ne vient pas de l'IP en tant que telle, mais de la façon dont votre code est conçu. Il mélange l'état de différentes sessions, perd les cookies, envoie d'anciens jetons depuis une nouvelle adresse. Nous allons apprendre à éviter tout ça.

Ce que vous obtiendrez au final

À la fin de ce guide, vous saurez faire plusieurs choses. Premièrement, comprendre ce qui est réellement lié à l'IP côté serveur et ce qui relève du mythe. Deuxièmement, établir une règle de correspondance stricte : une session logique = un ensemble de cookies = une IP. Troisièmement, écrire du code fonctionnel en Python et Node.js qui isole l'état entre différents proxys et ne mélange pas les données. Quatrièmement, sauvegarder l'état entre les exécutions du programme et savoir quand il est plus simple de tout jeter.

Pour qui est ce guide

Ce guide s'adresse à un niveau intermédiaire. Vous écrivez déjà du code en Python ou en JavaScript, vous savez ce qu'est une requête HTTP et vous comprenez l'intérêt des proxys. Nous n'allons pas discuter du type de rotation à choisir, car il existe des articles dédiés. Ici, nous partons du principe que la rotation d'IP se fait déjà selon vos règles, et nous résolvons une seule question : comment ne pas perdre l'état pendant cette rotation.

Ce qu'il faut savoir à l'avance

Il est utile de comprendre les bases. Un cookie est une petite donnée que le serveur demande au navigateur ou au client de mémoriser et de renvoyer avec chaque requête. Une session est la façon pour le serveur de vous reconnaître entre les requêtes. Un jeton est une chaîne qui prouve votre identité ou votre droit d'agir. Si ces termes sont encore flous, pas de panique : dans la section des concepts de base, nous allons les expliquer simplement.

Combien de temps cela prendra

La lecture et la compréhension de la théorie prendront environ quarante minutes. L'analyse et l'exécution du code dans votre langage prendront encore une heure à une heure et demie. L'assimilation complète avec des expériences sur des cas réels prendra deux à trois heures. Ne vous précipitez pas. Mieux vaut comprendre lentement le principe que de copier rapidement un code qui cassera ensuite sans explication.

Préparation : outils et environnement

Avant d'écrire du code, mettons en ordre votre environnement de travail. Cela prendra un peu de temps, mais vous gagnerez des heures de débogage ensuite.

Outils nécessaires

• Python 3.10 ou plus récent — si vous travaillez en Python. En 2026, les versions 3.12 et 3.13 sont courantes, mais tout ce qui est décrit fonctionne à partir de 3.10.
• Node.js 20 LTS ou plus récent — si vous travaillez en JavaScript. La version 22 LTS convient également.
• Proxys avec rotation d'IP — vous devez déjà avoir accès à un pool d'adresses. Le format de connexion est généralement : protocole, hôte, port, identifiant et mot de passe.
• Éditeur de code — n'importe lequel convient, par exemple un éditeur gratuit avec coloration syntaxique.
• Terminal ou ligne de commande — pour installer les bibliothèques et lancer les scripts.

Configuration système requise

Les exigences sont modestes. N'importe quel ordinateur récent fera l'affaire. Quatre gigaoctets de RAM suffisent, mais si vous prévoyez beaucoup de sessions parallèles, mieux vaut huit ou plus. La connexion internet stable est plus importante, car en cas de perte de connexion, les cookies peuvent ne pas être sauvegardés correctement.

Ce qu'il faut installer

Pour Python, installez deux bibliothèques. Ouvrez le terminal et exécutez la commande d'installation du paquet requests et du paquet pour travailler avec les proxys. Cela s'écrit ainsi : d'abord la commande d'installation du gestionnaire de paquets, puis le nom requests. Pour la sérialisation de l'état, le module standard suffit, pas besoin de l'installer séparément.

Pour Node.js, installez trois paquets : axios pour les requêtes, tough-cookie pour gérer le stockage des cookies et https-proxy-agent pour se connecter via un proxy. Les trois s'installent avec une seule commande d'installation de paquets dans votre projet.

Astuce : Créez un dossier virtuel séparé pour le projet. En Python, il s'agit de l'environnement virtuel ; en Node.js, d'un répertoire dédié avec un fichier de description des dépendances. Ainsi, vous ne mélangez pas les bibliothèques de différents projets et évitez les conflits de versions.

Création de sauvegardes

Si vous sauvegardez déjà les cookies dans des fichiers ou une base de données, faites une copie avant les expériences. Nous allons modifier la logique de sérialisation, et il y a un risque d'endommager les données existantes. Copiez simplement le dossier contenant les états sauvegardés vers un emplacement marqué « backup ».

Vérification : Après l'installation, assurez-vous que tout fonctionne. Lancez une rapide vérification de la version de Python ou de Node.js dans le terminal. Vous devriez voir le numéro de version sans erreur. Ensuite, essayez d'importer les bibliothèques installées en mode interactif — si l'import se fait sans message, tout est prêt.

Concepts de base : ce qui est lié à l'IP et ce qui est un mythe

C'est la section théorique la plus importante. Tant que vous n'aurez pas compris ce qui est réellement lié à l'IP, vous traiterez la mauvaise maladie. Passons en revue les types de données un par un.

Session basée sur les cookies

Une session basée sur les cookies, c'est quand le serveur vous délivre un identifiant de session sous forme de cookie et stocke l'état de son côté. Par exemple, un cookie nommé sessionid contenant une longue chaîne aléatoire. Le serveur utilise cette chaîne pour retrouver votre enregistrement en mémoire. Ce mécanisme est-il lié à l'IP ? En soi, non. Le cookie fonctionne indépendamment de l'adresse. Mais de nombreux services ajoutent une vérification supplémentaire : ils mémorisent l'IP à partir de laquelle la session a été créée, et si une requête avec le même cookie provient d'une autre adresse, ils la considèrent comme suspecte. C'est là que la déconnexion se produit.

Jeton CSRF

Le jeton CSRF est une protection contre la falsification de requêtes. Le serveur délivre un jeton que vous devez renvoyer lors de l'envoi d'un formulaire ou d'une action importante. Ce jeton n'est presque jamais lié à l'IP. Il est lié à la session, pas à l'adresse. Le problème survient pour une autre raison : si vous avez perdu le cookie de session, le jeton CSRF devient invalide, car le serveur ne peut pas le rattacher à votre session. En d'autres termes, le problème est secondaire — c'est une conséquence de la perte des cookies.

JWT

Le JWT est un jeton qui contient des informations en lui-même et est signé par le serveur. Le client le stocke et l'envoie dans l'en-tête à chaque requête. Un JWT classique n'est pas du tout lié à l'IP. Il est autonome : le serveur vérifie la signature et la date d'expiration, et l'adresse ne l'intéresse pas. Mais certaines implémentations ajoutent une liaison du jeton à l'IP côté serveur ou intègrent l'adresse dans le jeton. Dans ces cas, le changement d'IP casse la vérification. Ce n'est pas une propriété du JWT, mais une décision du service concerné.

Session serveur

La session serveur est le nom générique de l'état que le serveur stocke de son côté et associe à votre identifiant. Le panier, l'historique de navigation, le statut de connexion — tout cela se trouve souvent dans une session serveur. Le lien avec l'IP dépend des réglages du service. Certains, pour des raisons de sécurité, lient strictement la session à la première IP. D'autres tolèrent le changement d'adresse. En général, vous ne le savez pas à l'avance, donc vous devez coder comme si ce lien existait — c'est une stratégie sûre.

Le panier

Le panier est un cas particulier de session serveur ou de cookie. Dans les boutiques simples, le panier est stocké dans un cookie côté client. Dans les plus complexes, il est sur le serveur, lié à la session. Si le panier se vide après un changement d'IP, c'est qu'il était lié à une session serveur qui vérifie l'adresse. La solution est la même : ne pas changer d'IP au sein d'une même session logique, ou bien sauvegarder soigneusement l'ensemble des cookies.

En résumé : où l'IP intervient vraiment

Résumons. Le mécanisme HTTP des cookies, le CSRF et le JWT ne sont pas liés à l'IP. La liaison apparaît comme une vérification supplémentaire côté service, et vous ne pouvez pas la contrôler. La seule chose que vous contrôlez, c'est la correspondance entre la session, l'ensemble des cookies et l'IP de votre côté. De là découle la règle principale de ce guide.

Vérification : Testez votre compréhension. Si après un changement d'IP la session saute, mais qu'en revenant à l'ancienne IP tout se rétablit, alors le serveur vérifie strictement l'adresse. Si elle ne se rétablit même pas sur l'ancienne IP, c'est que vous avez simplement perdu les cookies dans le code. Ce sont deux diagnostics différents, avec des traitements différents.

Étape 1 : Formuler la règle de correspondance

Objectif de l'étape : assimiler le principe clé et comprendre comment l'exprimer dans la structure du code.

La règle est simple : une session logique = un ensemble de cookies = une IP. Voyons ce que cela signifie concrètement.

1. Une session logique est une chaîne de requêtes qui constituent un travail continu : vous arrivez, vous vous connectez, vous faites quelque chose, vous vous déconnectez. Tout cela est une seule session logique.
2. Un ensemble de cookies est un stockage de cookies distinct qui appartient uniquement à cette session logique et à personne d'autre.
3. Une IP : pendant une session logique, l'adresse ne change pas. Si une rotation a quand même eu lieu, la session logique est considérée comme terminée.

Comment exprimer cela dans le code ? Très concrètement : créez un objet conteneur qui renferme à la fois le stockage des cookies et la configuration du proxy. Tant que cet objet est vivant, la session logique est vivante. Quand il faut changer d'IP, soit vous créez un nouveau conteneur, soit, si le service tolère le changement d'adresse, vous transférez soigneusement les cookies dans un nouveau conteneur avec la nouvelle IP.

⚠️ Attention : L'erreur d'architecture la plus fréquente est de stocker un ensemble de cookies commun et d'y associer différents proxys. Cela casse tout, c'est garanti. Les différentes sessions logiques finissent par écraser les cookies des unes et des autres, et le serveur reçoit des données contradictoires. Ne faites jamais ça.

Astuce : Pensez à la session logique comme à une personne. Une personne a un seul jeu de documents (les cookies) et une seule maison (l'IP). Deux personnes ne peuvent pas utiliser les mêmes documents, et une personne ne peut pas vivre dans deux maisons en même temps. Cette analogie vous évitera la plupart des erreurs.

Vérification : Dessinez sur papier votre future structure. Vous devriez obtenir plusieurs blocs indépendants, chacun avec son stockage de cookies et son proxy. Aucune donnée partagée entre les blocs. Si c'est le cas, vous avez compris la règle.

Étape 2 : Pratique avec Python — une Session par proxy

Objectif de l'étape : écrire du code fonctionnel où chaque session logique possède son propre objet requests.Session, son propre CookieJar et son propre proxy, tous isolés les uns des autres.

Dans la bibliothèque requests, il existe l'objet Session. Il est lui-même un conteneur : il gère le stockage des cookies et applique les réglages à toutes les requêtes. C'est la base idéale pour notre session logique.

Structure de base

1. Créez une fonction qui prend les données d'un proxy et renvoie un objet Session prêt à l'emploi.
2. À l'intérieur de la fonction, créez un nouvel objet Session.
3. Définissez le réglage proxies sur l'objet — un dictionnaire avec l'adresse du proxy pour les protocoles http et https.
4. Renvoyez l'objet. Vous avez maintenant un conteneur isolé.

Voici à quoi ressemble le code. Ligne par ligne : on importe requests. On définit la fonction make_session, qui prend une chaîne proxy_url. À l'intérieur, on écrit s égale requests point Session parenthèses. Ensuite, s point proxies égale un dictionnaire où la clé http pointe vers proxy_url et la clé https pointe vers proxy_url. À la fin, return s. Et voilà, la fonction est prête.

Pourquoi cela isole l'état

Chaque appel à make_session crée un tout nouvel objet. Ce nouvel objet a son propre stockage interne de cookies, appelé cookiejar. Les cookies obtenus par une session ne peuvent physiquement pas arriver dans une autre session, car ce sont des objets différents en mémoire. C'est exactement ce que nous voulions.

Utilisation de la session

1. Obtenez l'objet session en appelant la fonction avec le proxy souhaité.
2. Effectuez les requêtes via les méthodes de cet objet : s point get ou s point post.
3. Les cookies que le serveur envoie dans l'en-tête Set-Cookie sont automatiquement stockés dans l'objet.
4. Lors des requêtes suivantes via le même objet, ces cookies sont renvoyés automatiquement.

Astuce : Ne créez pas un nouveau Session pour chaque requête individuelle au sein d'une même session logique. Sinon, les cookies ne s'accumuleront pas. Créez l'objet une seule fois pour toute la session logique et utilisez-le pour toutes les requêtes de cette session.

Isolation entre les threads

Si vous travaillez avec plusieurs threads, chaque thread doit avoir son propre objet Session. L'objet Session n'est pas thread-safe. Cela signifie que si deux threads écrivent des cookies dans le même objet en même temps, les données peuvent être corrompues.

1. Utilisez le mécanisme des données locales au thread. En Python, c'est l'objet threading.local.
2. Au démarrage de chaque thread, créez une session distincte et stockez-la dans le stockage local du thread.
3. À l'intérieur du thread, utilisez uniquement votre session et ne touchez pas à celles des autres.

Concrètement, cela donne : on crée un objet global local égal à threading point local parenthèses. Au début du travail du thread, on vérifie si local possède un attribut session. Si ce n'est pas le cas, on le crée en appelant make_session avec le proxy attribué à ce thread. Ensuite, dans le thread, on utilise local point session pour toutes les requêtes.

⚠️ Attention : Ne transmettez jamais un objet Session entre les threads comme ressource partagée. Même si les requêtes semblent se succéder, l'ordonnanceur peut changer de thread au pire moment, et vous vous retrouverez avec des cookies mélangés. À chaque thread, son objet.

Rotation dans la logique

Lorsque la rotation d'IP a eu lieu et que vous avez besoin d'une nouvelle adresse, procédez ainsi. Terminez la session logique actuelle : si le serveur lie strictement à l'IP, créez simplement un nouvel objet Session avec le nouveau proxy et repartez de zéro — reconnectez-vous. Si le serveur tolère le changement d'adresse, vous pouvez transférer les cookies, comme nous le verrons à l'étape sur le stockage de l'état.

Vérification : Lancez deux sessions avec des proxys différents, connectez-vous dans chacune sur un service de test qui affiche votre IP et vos cookies. Assurez-vous que chaque session voit sa propre IP et son propre ensemble de cookies. Si les données ne se mélangent pas, l'isolation fonctionne correctement.

Étape 3 : La même chose sur Node.js

Objectif de l'étape : construire une structure équivalente en JavaScript avec axios, tough-cookie et l'agent proxy.

Dans l'écosystème Node.js, il n'existe pas d'objet Session prêt à l'emploi, nous allons donc le construire à partir de trois éléments. Le stockage des cookies viendra de tough-cookie. L'agent assurera la connexion via le proxy. Axios s'occupera des requêtes.

Assemblage du conteneur

1. Importez la classe CookieJar depuis la bibliothèque tough-cookie.
2. Importez la fonction de création d'agent proxy depuis la bibliothèque https-proxy-agent.
3. Importez axios.
4. Créez une fonction makeClient qui prend l'adresse du proxy et renvoie un objet configuré.

À l'intérieur de la fonction, créez une nouvelle instance de stockage : const jar = new CookieJar(). Créez l'agent proxy en lui passant l'adresse : const agent = new HttpsProxyAgent(adresse du proxy). Créez une instance axios avec les réglages via la méthode axios.create, en lui passant httpsAgent égal à agent et httpAgent égal à agent.

Mise en place de la gestion automatique des cookies

Axios brut ne sait pas placer automatiquement les cookies de la réponse dans le stockage ni les récupérer pour une requête. Il y a deux options.

1. Première option : utiliser une wrapper prête à l'emploi qui relie axios et tough-cookie, installée comme un paquet séparé. Elle lit et écrit automatiquement les cookies via le stockage jar fourni.
2. Deuxième option : le faire manuellement à l'aide d'intercepteurs de requêtes et de réponses. Avant la requête, on récupère la chaîne de cookies depuis le stockage pour l'adresse concernée et on la place dans l'en-tête Cookie. Après la réponse, on prend l'en-tête Set-Cookie et on enregistre chaque cookie dans le stockage.

Astuce : Pour commencer, utilisez une wrapper prête à l'emploi — moins de risques d'erreur. Gardez l'option manuelle pour les cas où vous avez besoin d'un contrôle fin, par exemple pour journaliser chaque cookie.

Isolation entre les tâches parallèles

Le modèle de Node.js est différent — pas de threads, mais des tâches asynchrones dans un même thread d'événements. Mais le principe est le même : chaque session logique a son propre objet client, avec son propre jar et son propre agent.

1. Pour chaque tâche parallèle, appelez makeClient séparément.
2. Stockez les clients dans un tableau ou une carte, où la clé est l'identifiant de la tâche.
3. N'utilisez jamais un même jar pour plusieurs clients en même temps.

⚠️ Attention : Dans le code asynchrone, il est facile de partager accidentellement un même client entre plusieurs chaînes de promesses. Les cookies commenceront alors à se mélanger entre les sessions logiques. Vérifiez toujours que chaque chaîne utilise son propre client, créé par un appel distinct à makeClient.

Rotation sur Node.js

La logique est identique à Python. Quand vous avez besoin d'une nouvelle IP et que le service lie la session à l'adresse, créez un nouveau client avec le nouveau proxy et un nouveau jar vide, puis reconnectez-vous. Quand le service tolère le changement, transférez le contenu de l'ancien jar dans le nouveau client avec le nouvel agent.

Vérification : Créez deux clients avec des proxys différents. Envoyez des requêtes à un service de test qui reflète l'IP et les cookies. Assurez-vous que le premier client voit une IP et ses cookies, et le second une autre IP et les siens. Aucune intersection ne doit apparaître.

Étape 4 : Stocker l'état entre les exécutions

Objectif de l'étape : apprendre à sauvegarder les cookies sur le disque et à les restaurer au prochain lancement du programme, en tenant compte de leur durée de vie.

Il arrive souvent de devoir arrêter un script puis le relancer sans perdre l'authentification. Pour cela, les cookies doivent être sérialisés — transformés en texte et sauvegardés dans un fichier ou une base.

Sérialisation en Python

L'objet CookieJar de requests peut être sauvegardé de plusieurs manières. La plus portable consiste à regrouper les cookies dans un simple dictionnaire et à l'écrire au format JSON.

1. Parcourez tous les cookies de l'objet session via s point cookies.
2. Pour chaque cookie, collectez son nom, sa valeur, son domaine, son chemin et sa date d'expiration.
3. Regroupez tout cela dans une liste de dictionnaires.
4. Écrivez la liste dans un fichier au format JSON.

Pour la restauration, faites l'inverse : lisez le fichier, parcourez la liste et ajoutez chaque cookie dans un nouvel objet session à l'aide d'une méthode de définition de cookie en précisant le domaine et le chemin.

Astuce : Stockez avec les cookies l'identifiant du proxy ou au moins une mention indiquant à quelle session logique ils appartiennent. Ainsi, vous ne restaurerez pas des cookies étrangers avec une mauvaise IP et ne violerez pas la règle de correspondance.

Sérialisation en Node.js

La bibliothèque tough-cookie dispose d'une méthode de sérialisation intégrée. L'objet jar possède une méthode asynchrone qui transforme tout le stockage en objet JSON. La méthode inverse restaure le jar à partir de cet objet.

1. Appelez la méthode de sérialisation du stockage et obtenez un objet.
2. Transformez l'objet en chaîne et enregistrez-le dans un fichier.
3. Au démarrage, lisez le fichier, analysez la chaîne pour revenir à l'objet.
4. Restaurez le jar à l'aide de la méthode de désérialisation en lui passant l'objet.

C'est plus pratique qu'en Python, car tough-cookie stocke lui-même tous les champs nécessaires, y compris la date d'expiration et les drapeaux de sécurité.

Durée de vie des cookies

Chaque cookie a une date d'expiration. Certains cookies sont de session — ils vivent jusqu'à la fermeture du navigateur et n'ont pas de date explicite. D'autres sont persistants — avec une date d'expiration précise. Il ne vaut la peine de sauvegarder sur le disque que les cookies persistants dont la date n'est pas encore expirée. Les cookies de session sont généralement déjà invalides côté serveur après un redémarrage.

1. Avant la sauvegarde, vérifiez la date d'expiration de chaque cookie.
2. Éliminez celles qui ont déjà expiré.
3. À la restauration, vérifiez à nouveau les dates et ne chargez pas les cookies périmés.

Quand il est plus simple de jeter l'état

Il ne faut pas toujours s'accrocher aux cookies sauvegardés. Parfois, un départ propre est plus rapide et plus fiable.

• Si beaucoup de temps s'est écoulé depuis le dernier lancement, la session sur le serveur a probablement expiré, il n'y a rien à restaurer.
• Si le serveur renvoie une erreur d'authentification dès la première requête avec les cookies restaurés, jetez-les et reconnectez-vous.
• Si vous n'êtes pas sûr de l'intégrité du fichier d'état, mieux vaut repartir de zéro que de déboguer un comportement étrange.

⚠️ Attention : Les fichiers contenant les cookies et les jetons contiennent des données d'accès. Stockez-les dans un endroit sécurisé, ne les placez pas dans un dépôt public, ne les envoyez pas par des canaux non sécurisés. La fuite d'un tel fichier équivaut à une fuite d'accès au compte.

Vérification : Sauvegardez l'état, fermez complètement le programme, relancez-le, restaurez l'état et faites une requête nécessitant une authentification. Si le serveur répond comme à un utilisateur connecté, la sauvegarde fonctionne. S'il déconnecte, vérifiez les dates d'expiration et la restauration correcte du domaine et du chemin.

Étape 5 : Analyse des erreurs d'architecture courantes

Objectif de l'étape : examiner en détail les trois principales erreurs afin que vous puissiez les reconnaître dans votre code et les éviter.

Erreur n°1 : un CookieJar commun pour tous les proxys

C'est la racine du mal. Le développeur crée un seul stockage de cookies et lui associe différents proxys, pensant économiser des ressources. Résultat : les cookies de la session sur la première IP se retrouvent dans la requête sur la seconde IP. Le serveur voit un cookie créé sous une autre adresse et soit réinitialise la session, soit considère le comportement comme suspect.

La solution est simple : chaque proxy a son propre stockage de cookies. Aucune exception. Nous l'avons déjà intégré dans les étapes de code : un Session distinct ou un client distinct avec un jar distinct pour chaque session logique.

Erreur n°2 : course lors de requêtes parallèles

Une course, c'est quand deux opérations accèdent aux mêmes données en même temps et se gênent mutuellement. Si deux threads écrivent dans le même CookieJar, une écriture peut écraser l'autre. Résultat : une partie des cookies est perdue au hasard, et le bug ne se reproduit pas à chaque fois, ce qui est pénible à déboguer.

1. Donnez à chaque thread sa propre session via les données locales au thread, comme nous l'avons décrit.
2. Dans le code asynchrone, ne partagez pas un même client entre des chaînes de tâches indépendantes.
3. Si, pour une raison quelconque, l'objet est partagé, utilisez un verrou pour qu'un seul thread travaille avec à la fois.

Astuce : La meilleure façon d'éviter une course est de ne pas avoir du tout de données mutables partagées. L'isolation par sessions logiques résout le problème à la racine : si les données ne sont pas partagées, il n'y a pas de course possible.

Erreur n°3 : perte de Set-Cookie lors des redirections

Quand le serveur répond par une redirection, il définit souvent des cookies importants dans la même réponse via l'en-tête Set-Cookie. Certains réglages du client perdent ces cookies lors du suivi automatique de la redirection — ils n'arrivent pas dans le stockage.

1. Assurez-vous que votre client enregistre les cookies à chaque étape de la chaîne de redirections, et pas seulement sur la réponse finale.
2. Dans requests, cela fonctionne par défaut avec l'objet Session — les cookies sont collectés en cours de route. Vérifiez que vous n'avez pas désactivé le suivi des redirections sans raison.
3. Dans axios, si vous gérez les cookies manuellement, traitez Set-Cookie sur chaque réponse intermédiaire. Si vous utilisez une wrapper, vérifiez qu'elle capture bien les redirections.

⚠️ Attention : Si l'authentification réussit mais que la requête suivante déconnecte, la cause fréquente est précisément un cookie perdu lors d'une redirection. Activez la journalisation de tous les en-têtes Set-Cookie et vérifiez que tous les cookies attendus arrivent bien dans le stockage.

Vérification : Trouvez sur le service cible une action qui provoque une redirection, par exemple une connexion via formulaire. Suivez la chaîne et comparez les cookies après chaque étape. Tous les cookies émis doivent se retrouver dans votre stockage. Si l'un d'eux manque, vous avez trouvé la fuite.

Étape 6 : Tout assembler dans un flux de travail

Objectif de l'étape : réunir ce que vous avez appris dans un flux de travail unique et prévisible, du démarrage à la rotation.

Vous avez maintenant toutes les pièces. Réunissons-les dans une séquence d'actions reproductible.

1. Prenez un proxy de votre pool et créez une session logique isolée : Session en Python, client en Node.js.
2. Si un état sauvegardé existe pour cette session logique et n'est pas périmé, restaurez les cookies. Sinon, reconnectez-vous.
3. Effectuez les requêtes nécessaires via l'objet de cette session. Les cookies s'accumulent automatiquement.
4. Sauvegardez régulièrement l'état sur le disque pour ne pas perdre la progression en cas de panne.
5. Quand le moment de la rotation d'IP arrive, terminez la session logique proprement.
6. Si le service lie strictement l'IP, démarrez une nouvelle session logique de zéro sur la nouvelle adresse.
7. Si le service tolère le changement, créez un nouveau conteneur avec le nouveau proxy et transférez-y les cookies de l'ancien.

Astuce : Tenez un journal des événements : quand une session a été créée, avec quelle IP, quand la rotation a eu lieu, s'il y a eu une déconnexion. Un tel journal révélera en cinq minutes une tendance que vous chercheriez sinon pendant des heures.

Vérification : Déroulez le cycle complet : création de session, authentification, quelques actions, sauvegarde, rotation, continuation. Assurez-vous qu'à chaque étape, l'état se comporte de manière prévisible et que la déconnexion ne se produit que lorsque vous l'attendez.

Vérification du résultat : la checklist finale

Parcourez cette liste. Si tous les points sont satisfaits, votre système fonctionne correctement.

• Chaque session logique possède un objet conteneur séparé avec son propre stockage de cookies.
• Chaque conteneur est lié à exactement un proxy pendant toute la durée de vie de la session.
• Il n'y a aucun endroit où les cookies d'une session peuvent passer dans une autre.
• Dans le code multithread, chaque thread utilise sa propre session via les données locales au thread.
• Dans le code asynchrone, chaque chaîne indépendante a son propre client.
• Les cookies sont correctement collectés à toutes les étapes des redirections.
• L'état est sauvegardé et restauré entre les exécutions, en tenant compte des dates d'expiration.
• Lors d'un changement d'IP, la session logique soit recommence, soit les cookies sont transférés en toute conscience.
• Les fichiers contenant les cookies et les jetons sont stockés en toute sécurité.

Comment tester

1. Trouvez un service de test qui affiche votre IP actuelle et les cookies reçus.
2. Créez deux sessions avec des proxys différents et vérifiez l'isolation totale des données.
3. Connectez-vous, sauvegardez l'état, redémarrez le programme, restaurez — vérifiez que l'authentification est toujours valide.
4. Simulez une rotation et observez comment la session se comporte.

Critères de réussite : les données des différentes sessions ne se mélangent jamais, la déconnexion ne se produit que lors d'une liaison stricte de l'IP côté serveur, l'état restauré fonctionne, et aucune course n'apparaît en parallèle.

Erreurs courantes et solutions

Problème : après un changement d'IP, l'utilisateur est déconnecté. Cause : le serveur lie strictement la session à l'adresse. Solution : ne pas changer d'IP au sein d'une même session logique, et si un changement est nécessaire, recommencer la session sur la nouvelle adresse.

Problème : les cookies de différentes sessions se mélangent. Cause : un CookieJar commun pour plusieurs proxys. Solution : donner à chaque session logique un stockage séparé et ne jamais le partager.

Problème : le bug se manifeste une fois sur deux en parallèle. Cause : une course lors de l'écriture dans un objet partagé depuis plusieurs threads. Solution : isoler les sessions par thread via les données locales au thread ou utiliser un verrou.

Problème : l'authentification réussit mais saute immédiatement. Cause : perte d'un cookie lors d'une redirection. Solution : vérifier la collecte des cookies à toutes les étapes de la chaîne de redirections et activer la journalisation de Set-Cookie.

Problème : l'état restauré ne fonctionne pas. Cause : des cookies périmés ou de session ont été sauvegardés, ou le domaine et le chemin sont incorrects. Solution : ne sauvegarder que les cookies persistants encore valides et restaurer avec le bon domaine et le bon chemin.

Problème : le jeton CSRF est constamment invalide. Cause : le cookie de session lié au jeton a été perdu. Solution : rétablir d'abord l'intégrité des cookies de session, le jeton suivra automatiquement.

Problème : le JWT cesse de fonctionner après une rotation. Cause : le service concerné a lié le jeton à l'IP de son côté. Solution : ne pas changer d'IP pendant la durée de vie du jeton, ou obtenir un nouveau jeton sur la nouvelle adresse.

Fonctionnalités supplémentaires et optimisation

Une fois le schéma de base en place, vous pouvez l'améliorer.

Pool de sessions prêtes

Au lieu de créer une session à chaque fois, gardez un pool de sessions logiques déjà préparées et authentifiées, chacune avec son proxy. Prenez une session libre, utilisez-la, remettez-la dans le pool. Cela accélère le travail car l'authentification n'est pas répétée inutilement.

Vérification automatique de la validité

Ajoutez une fonction qui envoie une requête légère au service et vérifie si la session est toujours valide. Si le serveur répond comme à un utilisateur non authentifié, la session est marquée pour une ré-authentification. Vous détectez ainsi l'expiration avant qu'elle ne gâche une opération importante.

Astuce : Effectuez la vérification de validité non pas avant chaque requête, mais selon un calendrier ou après de longues pauses. Des vérifications trop fréquentes créent une charge inutile et n'apportent rien.

Stockage centralisé des états

Pour les projets importants, utilisez une base de données comme stockage des cookies au lieu de fichiers. La clé est l'identifiant de la session logique, la valeur est l'état sérialisé. C'est plus facile à faire évoluer et plus sûr à conserver.

Métriques et observabilité

Comptez combien de fois une déconnexion se produit, combien de sessions ont dû être recréées, à quelle fréquence la restauration réussit. Ces chiffres révèlent la santé de votre système et vous indiquent où quelque chose est réglé de manière sous-optimale.

FAQ : questions fréquentes

Faut-il obligatoirement créer un nouvel objet session à chaque changement d'IP ? Si le service vérifie strictement l'adresse, oui, car l'ancienne session sur la nouvelle IP ne sera de toute façon pas acceptée. Si le service tolère, vous pouvez transférer les cookies dans un nouveau conteneur avec le nouveau proxy et continuer.

Peut-on utiliser un même proxy pour plusieurs sessions logiques ? Côté code, oui, mais chaque session logique doit quand même avoir son propre stockage de cookies. Seuls les réglages de connexion peuvent être partagés, jamais l'état.

Pourquoi ne pas simplement stocker tous les cookies au même endroit et filtrer par domaine ? Parce que le problème ne vient pas du domaine, mais de la liaison avec une session logique et une IP spécifiques. Les cookies d'une session sur un domaine donné ne doivent pas arriver dans une autre session sur le même domaine.

Comment savoir si un service lie la session à l'IP ? Faites une expérience : connectez-vous sur une IP, changez d'adresse et envoyez une requête. Si vous êtes déconnecté, il y a probablement une liaison. Revenez à l'ancienne IP : si tout se rétablit, le serveur a mémorisé la première adresse.

Que faire des cookies de session lors de la sauvegarde sur le disque ? Il n'y a généralement pas d'intérêt à les conserver, car le serveur les considère comme invalides après la coupure de connexion. Sauvegardez les cookies persistants avec une durée de vie valide.

Que faire si la bibliothèque ne sauvegarde pas elle-même les cookies lors d'une redirection ? Traitez l'en-tête Set-Cookie manuellement sur chaque réponse intermédiaire de la chaîne de redirections et déposez les cookies dans votre propre stockage.

Faut-il un verrou si chaque thread a sa propre session ? Non. Si les données ne sont pas partagées, il n'y a pas de course possible et le verrou n'est pas nécessaire. Un verrou n'est requis que lorsqu'un accès partagé à un même objet est inévitable.

Combien de temps peut-on conserver un état restaurable ? Jusqu'à ce que le serveur considère la session comme active, pas plus. La durée exacte dépend du service. Il est plus pratique de vérifier la validité par une requête que de deviner à l'avance.

Qu'est-ce qui est le plus important : conserver les cookies ou conserver le jeton ? Cela dépend du mécanisme d'authentification du service. Parfois le jeton suffit, parfois il faut l'ensemble des cookies. Le plus sûr est de sauvegarder tout l'état, ainsi vous ne manquerez rien.

Peut-on transférer des cookies entre Python et Node.js ? Oui, si vous les sauvegardez dans un format neutre commun comme JSON avec les champs nom, valeur, domaine, chemin et date d'expiration. Ainsi, n'importe lequel des systèmes pourra les lire.

Conclusion

Récapitulons ce que vous avez parcouru. Vous avez compris qu'après un changement d'IP, la déconnexion n'est pas due au changement en lui-même, mais aux vérifications du serveur et aux erreurs de votre architecture. Vous avez appris que les cookies, le CSRF et le JWT ne sont pas liés à l'adresse en eux-mêmes ; c'est le service concerné qui ajoute ce lien. Vous avez intégré la règle principale : une session logique = un ensemble de cookies = une IP.

Ensuite, vous avez écrit du code fonctionnel. En Python, via un objet Session séparé avec son propre CookieJar pour chaque proxy et une isolation par threads. En Node.js, via l'association axios, tough-cookie et agent proxy, avec un client séparé pour chaque session logique. Vous avez appris à sauvegarder l'état entre les exécutions, à tenir compte des dates d'expiration des cookies et à savoir quand il est plus simple de tout jeter.

Vous avez analysé trois erreurs sournoises : le CookieJar commun, la course en parallèle et la perte de Set-Cookie lors des redirections. Vous disposez maintenant d'une checklist avant mise en production qui vous empêchera de livrer une solution bancale.

Que faire ensuite

Commencez petit. Prenez un scénario réel, implémentez une session logique isolée pour lui et vérifiez que l'état ne se perd pas. Ajoutez ensuite la sauvegarde sur le disque. Puis passez à plusieurs sessions. Avancez étape par étape, en vérifiant le résultat à chaque fois.

Comment aller plus loin

Ensuite, il est utile de creuser l'observabilité : mettre en place des métriques de validité des sessions et la journalisation des événements. Puis, apprenez à transférer l'état en toute conscience lorsque le service tolère le changement d'adresse. Enfin, construisez un pool de sessions prêtes pour accélérer le travail. Chacune de ces étapes rend votre système plus robuste et plus prévisible. Vous y arriverez — vous avez déjà compris le principe, le reste est une affaire de pratique.