La question « combien de threads un port peut-il supporter » se pose le plus souvent avant de lancer un scraping massif ou le préchauffage de dizaines de comptes, et il n'existe pas de chiffre universel. La limite dépend de la combinaison de trois éléments : la bande passante du canal, la politique du fournisseur et le comportement du site cible sous charge parallèle. Voyons ce qui limite réellement le nombre de threads et comment éviter d'atteindre cette limite dès le démarrage de la tâche.

De quoi dépend la limite de parallélisme

Le premier facteur est la bande passante du canal côté fournisseur. Les adresses de datacenter et ISP reposent généralement sur un canal dédié large et supportent des dizaines de connexions simultanées sans dégradation. Le trafic résidentiel et mobile passe par un abonné réel ou un réseau cellulaire : le canal y est plus étroit, et une hausse linéaire du nombre de threads se heurte plus vite à la latence et à la perte de paquets. La différence entre ces canaux est détaillée dans l'article proxys mobiles ou résidentiels.

Le deuxième facteur est constitué par les limites du fournisseur lui-même. Certains forfaits vendent un port avec une restriction formelle du nombre de connexions parallèles : tout dépassement est soit bloqué, soit se traduit par des connexions nouvelles qui ne s'établissent tout simplement pas. Cette restriction figure dans les conditions du forfait et n'a rien à voir avec la qualité du canal : elle est artificielle et se lève en passant à un forfait plus large ou en ajoutant des ports.

Le troisième facteur, souvent décisif, est le site cible lui-même. Il applique sa propre limite de requêtes par adresse IP et par unité de temps, généralement inférieure à ce que le canal peut absorber. Même un port sans limite de threads se heurte à ce plafond : le site renvoie un captcha, un bannissement temporaire de l'IP ou des réponses vides bien avant que le canal du proxy ne soit saturé.

Signes de surcharge

La surcharge ressemble rarement à une erreur explicite du type « limite dépassée » : elle se déguise le plus souvent en instabilité. Le premier signe est la hausse des délais d'attente dépassés : les requêtes qui répondaient auparavant en une fraction de seconde se mettent à rester bloquées et à être interrompues par le délai d'attente du client. Le deuxième est la hausse de la part des connexions interrompues avant la réception d'une réponse, alors que le site cible fonctionne normalement avec d'autres adresses. Ces indicateurs sont à suivre selon les mêmes principes que ceux décrits dans l'article comment vérifier la qualité d'un proxy.

Le troisième signe est une hausse nette de la part de captchas et de blocages temporaires précisément depuis cette IP, avec un scénario de requêtes inchangé. Si le captcha n'apparaissait auparavant que de temps en temps sur mille requêtes et qu'il survient désormais une fois sur dix après l'augmentation du nombre de threads, ce n'est pas un hasard : c'est le signal que le parallélisme a dépassé à la fois la limite du site et le seuil raisonnable pour une seule adresse.

Pourquoi plus de threads ne signifie pas plus de vitesse

On a l'impression intuitive que doubler les threads double la vitesse de collecte, mais en pratique la courbe atteint rapidement un plateau, puis redescend. Chaque requête interrompue par un délai d'attente dépassé n'est pas seulement une tentative perdue, c'est un effet secondaire toxique : le script la répète, ce qui alourdit la charge sur la même IP, ou bien perd des données qu'il faudra ensuite récupérer lors d'un passage séparé.

Dès que le site se met à répondre par un captcha au lieu du contenu, la vitesse de traitement utile chute plus vite que n'augmente le nombre de connexions : une partie des threads perd du temps à résoudre ou contourner le captcha au lieu de collecter des données, et une autre reçoit une réponse inutilisable qu'il faut écarter et redemander. L'optimum se situe presque toujours en dessous du maximum technique du canal, à l'endroit où la part d'erreurs et de répétitions est minimale, et non là où tout le canal est chargé.

Comment répartir la charge entre les ports

Lorsqu'une tâche exige plus de parallélisme qu'une seule adresse ne peut en supporter sans risque, la solution n'est pas de « tirer le maximum du port », mais de répartir la charge sur plusieurs ports dotés d'IP différentes. Le site voit chaque adresse comme un visiteur distinct, avec sa propre limite de requêtes par unité de temps ; ainsi, dix ports à cinq threads sûrs offriront un débit stable supérieur à celui d'un seul port poussé de force à cinquante threads.

L'approche pratique consiste à commencer par un nombre prudent de threads par adresse, à l'augmenter progressivement et à repérer le moment où les délais d'attente dépassés ou la part de captchas augmentent, puis à rester nettement en dessous de cette limite. Pour les canaux résidentiels et mobiles avec attribution d'adresse par session, la rotation des IP entre les requêtes allège à elle seule la charge sur chaque adresse, car le site voit des IP différentes au lieu d'une seule adresse surchargée ; la manière de configurer cette rotation via l'API est expliquée dans un article dédié sur la rotation des IP.

Lien entre threads et consommation de trafic

Le nombre de threads multiplie directement la consommation de trafic, et pas seulement la vitesse. Les canaux résidentiels et mobiles sont facturés au gigaoctet ; un parallélisme agressif sans désactivation du chargement multimédia superflu (images, polices, lecture automatique) épuise donc le budget de trafic bien plus vite que n'augmente le résultat utile. Ordre de grandeur : mille vérifications de fiches produit avec images représentent environ 3 à 5 Go, mille pages de texte environ 1 Go ; lorsque le nombre de threads augmente, ces chiffres se multiplient de façon linéaire, et il vaut mieux prévoir le budget à l'avance plutôt que de le calculer après l'épuisement du solde.

Questions fréquentes

Existe-t-il un nombre universel de threads « par port » ?

Non, car la limite est déterminée par le site cible autant que par le canal. Pour un site, trente requêtes parallèles depuis une adresse restent confortables ; pour un autre, la surcharge commence dès cinq. Il faut partir du comportement du site concerné, et non d'une norme abstraite.

Que se passe-t-il si l'on dépasse la limite du fournisseur en connexions parallèles ?

En général, les connexions au-delà de la limite ne s'établissent pas, ou bien une partie des sessions déjà ouvertes est interrompue ; le comportement dépend du forfait. Il ne s'agit pas d'une dégradation de la qualité du canal, mais d'une restriction stricte, qui se lève en passant à un forfait avec une limite plus élevée ou en ajoutant des ports.

La rotation des IP permet-elle de maintenir plus de threads simultanément ?

Oui, indirectement : si chaque nouvelle requête ou session reçoit une nouvelle adresse, la limite du site cible est recalculée pour chaque IP au lieu de s'accumuler sur une seule. Cela n'annule pas les restrictions du canal et du forfait, mais allège la part de charge liée aux limites du site par adresse.

Les tarifs en vigueur selon le nombre de threads et les types de canaux se trouvent dans la section proxys. Vous pouvez aussi y acheter des ports supplémentaires pour répartir la charge, sans pousser une seule adresse au-delà de son seuil de sécurité.