De combien de serveurs proxy avez-vous réellement besoin ?

Nous vendons des proxys sur Geonode, ce qui fait de cet article un plaidoyer en faveur d’une réduction de vos achats par rapport à ce que vous aviez prévu. C'est véritablement notre position : un parc de proxys surdimensionné ne vous apporte pas plus de sécurité, et avec une tarification basée sur le trafic, cela ne coûte même pas plus cher — ce qui signifie que les gens se font une fausse idée sans jamais voir la facture qui permettrait de la corriger. Le chiffre qui compte, c'est la concurrence sur une cible unique, et cela se mesure en un après-midi. Si vous ne devez retenir qu’une seule chose de cet article, que ce soit la mesure présentée dans la section suivante plutôt que n’importe quel chiffre que nous pourrions vous donner.

La seule méthode qui fonctionne

Trois étapes, toutes empiriques.

Première étape : déterminez le plafond par adresse. Exécutez votre charge de travail réelle à partir d’une seule adresse, en augmentant progressivement le débit de requêtes, et identifiez le moment où la cible commence à montrer des signes de saturation — codes 429, messages d’alerte, réponses plus lentes ou contenu dégradé. Ce seuil correspond à votre capacité par adresse pour cette cible, et c’est le seul chiffre de ce calcul qui ne repose pas sur une estimation.

Deuxième étape : définissez le débit requis. Combien de requêtes, sur quelle durée. Soyez honnête concernant la durée, car c’est l’élément le plus déterminant dans cette équation.

Étape 3 : divisez. Le débit requis divisé par la capacité par adresse donne le nombre d’adresses simultanées nécessaires. Ajoutez une marge pour les nouvelles tentatives et la variabilité — 50 % est une estimation généreuse, et si vous avez besoin de plus que cela, votre mesure à l’étape 1 était probablement trop optimiste.

Voilà toute la méthode. La raison pour laquelle ce n’est pas le conseil habituel, c’est qu’elle nécessite d’effectuer un test avant l’achat, et les fournisseurs n’ont aucun intérêt à la suggérer.

Remarque concernant la première étape : mesurez le nombre de réponses utiles complètes par seconde, et non le nombre de requêtes tentées. Un pool renvoyant des codes 200 avec un contenu tronqué ne fonctionne pas, mais un indicateur de taux de réussite global le signalera comme étant en bon état. Recherchez un marqueur connu pour être stable dans la réponse et ne comptez que les réponses qui le contiennent.

Effectuer correctement la mesure

Toute la méthode repose sur la première étape ; il est donc important d’être précis sur la manière de la réaliser sans se tromper.

Testez par rapport à votre cible réelle, et non à un point de terminaison de test. Un test effectué sur un service qui renvoie votre adresse IP vous indique simplement que votre proxy fonctionne, mais ne vous renseigne en rien sur la manière dont le site qui vous intéresse vous traitera. Chaque cible a sa propre tolérance, et la valeur dont vous avez besoin dépend spécifiquement de la cible.

Augmentez progressivement le débit et enregistrez tout. Commencez bien en dessous de ce que vous estimez être la limite, puis augmentez progressivement, en maintenant chaque débit suffisamment longtemps pour observer une tendance — au moins quelques minutes. Enregistrez le débit, les codes d’état, la taille des réponses et le temps réel pour chaque étape :

for rate in 0.2 0.5 1 2 5 10; do
  echo "=== $rate req/s"
  for i in $(seq 1 60); do
    code=$(curl -s -x "$PROXY" -o /tmp/body -w '%{response_code}' "$URL")
    size=$(stat -c%s /tmp/body 2>/dev/null || stat -f%z /tmp/body)
    echo "$rate $code $size"
    sleep "$(echo "1/$rate" | bc -l)"
  done
done | tee ramp.log

Surveillez la taille des réponses aussi attentivement que les codes d’état. La forme la plus courante de rejet n’est pas un code 429, mais un code 200 accompagné d’une page plus petite. Une baisse de la taille moyenne de réponse à un débit donné indique que la cible commence à vous servir un contenu allégé, ce qui passe inaperçu si vous ne tenez compte que des codes d’état.

Exécutez le test à différents moments de la journée. La tolérance est souvent plus faible pendant les heures de pointe d’un site, et une limite mesurée à 3 h du matin ne tiendra pas à midi. Prenez la valeur la plus pessimiste.

Répétez l’opération avec une deuxième adresse. Si une adresse atteint ses limites à deux requêtes par seconde et qu’une deuxième adresse atteint ces mêmes limites au même moment, la limite n’est pas propre à chaque adresse — elle concerne votre sous-réseau, la structure de vos requêtes ou un autre facteur que l’ajout d’adresses supplémentaires ne résoudra pas. Il s’agit d’un résultat négatif important, dont l’obtention nécessite un test supplémentaire.

Arrêtez-vous donc avant le plafond, et non pas au niveau de celui-ci. Fonctionner au débit maximal que la cible peut tolérer signifie que la moindre fluctuation ordinaire vous fera dépasser ce seuil. Choisir une capacité comprise entre 60 et 70 % du plafond mesuré vous garantit une tâche qui s’exécute de manière fiable, plutôt qu’une tâche qui ne s’achève que lorsque les conditions sont favorables.

Exemple pratique : suivi quotidien des prix

La charge de travail la plus courante, et celle dont la réponse surprend le plus.

Exigence : 50 000 pages de produits vérifiées une fois par jour.

Plafond mesuré : la cible tolère environ une requête toutes les deux secondes provenant d’une même adresse avant d’appliquer une limitation de débit — soit environ 1 800 requêtes par heure.

Répartition sur 24 heures : 50 000 ÷ 24 ≈ 2 100 requêtes par heure.

Nombre d’adresses nécessaires : 2 100 ÷ 1 800 ≈ 1,2. Arrondissons à la hausse et ajoutons une marge : deux à quatre adresses.

Deux adresses. Pour cinquante mille pages par jour, face à un pool de plusieurs millions.

Modifions maintenant une hypothèse. Supposons que la tâche doive être terminée dans un délai de deux heures plutôt que d’être répartie sur toute la journée :

Exigence : 50 000 pages en 2 heures = 25 000 par heure. Adresses nécessaires : 25 000 ÷ 1 800 ≈ 14, plus une marge : environ 20.

Même volume, même objectif, dix fois plus d’adresses — en raison d’une décision de planification, et non d’une exigence de collecte de données.

C’est là l’idée la plus utile de cet article. Le délai que vous vous accordez est la variable déterminante. Avant d’acheter davantage d’adresses, demandez-vous si le travail doit réellement être terminé rapidement, et quelle valeur vous accordez à cette rapidité. Souvent, elle n’a aucune valeur, car les données sont utilisées dès le lendemain matin.

Exemple pratique : vérifications géographiques

Une configuration totalement différente, et les calculs s'effectuent dans l'autre sens.

Exigence : vérifier les tarifs régionaux et la disponibilité sur 30 marchés, quatre fois par jour, à raison de 50 pages par marché.

Volume : 30 × 4 × 50 = 6 000 requêtes par jour. Un jeu d’enfant.

Adresses nécessaires pour le débit : essentiellement une seule. Six mille requêtes réparties sur une journée, cela représente une requête toutes les quatorze secondes.

Adresses nécessaires pour la couverture : au moins une sortie opérationnelle dans chacun des 30 pays, au moment où vous en avez besoin.

Ici, la contrainte n’est absolument pas le volume, mais la présence. Ce que vous devriez évaluer, c’est si le fournisseur dispose réellement d’une couverture fiable sur les marchés spécifiques dont vous avez besoin, aux moments où vous effectuez vos opérations — et non le nombre d’adresses que contient le pool. Un pool de dix millions d’adresses avec une couverture insuffisante sur trois de vos marchés est pire qu’un pool de dix mille adresses couvrant l’ensemble des trente.

C’est pourquoi « de combien ai-je besoin ? » n’est pas la bonne question à se poser pour un travail géographique, tandis que « où pouvez-vous atteindre vos cibles de manière fiable, et puis-je le tester ? » est la bonne.

Exemple pratique : gestion des sessions

Le cas où concurrence et identité ne font qu’un.

Exigence : gérer en parallèle 10 sessions authentifiées, chacune exécutant des séquences en plusieurs étapes.

Adresses nécessaires : 10, et elles doivent être « collantes » (sticky) — une seule adresse conservée pendant toute la durée de chaque session.

Le volume n’a ici aucune importance. Ce qui compte, c’est que chaque session dispose d’une identité cohérente : la même adresse tout au long de la session, avec les mêmes paramètres régionaux et le même fuseau horaire. Une session dont les requêtes proviennent de quatre pays différents n’est pas une session, mais un modèle.

L’erreur à éviter est d’utiliser pour cela un point de terminaison tournant à chaque requête, ce qui est le comportement par défaut de la plupart des passerelles. Les requêtes aboutissent, l’état de la session est perdu, et le symptôme ressemble à un bug de l’application jusqu’à ce que quelqu’un vérifie les adresses de sortie.

Notez également que dix sessions simultanées ne signifient pas dix adresses pour toujours — cela signifie dix à la fois. Une charge de travail exécutant 200 sessions de manière séquentielle tout au long de la journée n’a toujours besoin que de dix adresses fixes, réutilisées.

Pourquoi « plus » ne signifie pas « plus sûr »

C'est l'hypothèse qui sous-tend la plupart des achats excessifs, et elle est erronée à trois égards précis.

Le blocage s'effectue par sous-réseau, et non par adresse. Les sites bloquent généralement au niveau d'/24. Cinquante adresses d’un même bloc se comportent comme une seule adresse lorsque ce bloc est bloqué ; ainsi, un grand pool mal réparti n’est pas un grand pool au sens où cela importe. La répartition prime sur le nombre, et nous avons abordé les mécanismes dans Qu’est-ce qu’un identifiant de sous-réseau ?.

C’est le rythme qui est révélateur, pas l’identité. Si vos requêtes semblent automatisées en raison de leur timing, de leurs en-têtes ou de leur empreinte TLS, les répartir sur davantage d’adresses diffuse le signal sans le supprimer. Vous finissez par signaler davantage d’adresses plutôt que moins.

Les adresses inutilisées perdent de leur valeur. Dans un pool tournant, une adresse que vous n’avez pas utilisée n’a aucun lien avec la cible, qu’il soit positif ou négatif. Disposer d’une « capacité de réserve » ne constitue pas une réserve de quoi que ce soit.

Il existe une seule raison valable de disposer de plus d’adresses que ne l’exige le débit : le renouvellement. Si une cible marque des adresses au fil du temps, vous avez besoin de remplacements à faire tourner. Il s’agit d’une exigence réelle, dont l’ampleur est déterminée par le taux de marquage observé plutôt que par l’intuition — mesurez le nombre d’adresses qui se dégradent chaque jour et conservez-en l’équivalent de quelques jours.

Ce que vous achetez réellement

Il convient de le préciser clairement, car la réponse varie selon le modèle de tarification et cela modifie même le sens de la question.

Dans le cadre d’une tarification au gigaoctet, qui correspond au mode de vente du trafic résidentiel et souvent celui des centres de données, vous n’achetez pas du tout d’adresses. Vous achetez du trafic, et le nombre d’adresses relève du pool plutôt que de votre forfait. Se demander « de combien de proxys ai-je besoin » dans ce contexte est une erreur de catégorie : les vraies questions sont de savoir quel volume de trafic vous allez transférer et si le pool couvre les zones où vous en avez besoin. Notre trafic résidentiel est proposé à partir de 0,79 $/Go et celui des centres de données à partir de 0,14 $/Go, selon les informations vérifiées en septembre 2026 sur notre page de tarifs.

Concernant la tarification à l’adresse IP, qui est le mode de vente des FAI et de nombreux produits de centres de données, le nombre d’adresses correspond littéralement à ce que vous payez et tout ce calcul relève du budget. Nos tarifs sont de 1,25 $ par adresse IP. Ici, le calcul ci-dessus porte sur l’argent, et il vaut la peine de consacrer vingt minutes à le faire correctement.

Le modèle qui vous convient dépend de la nature de votre charge de travail plutôt que du tarif affiché, et les deux ne sont pas comparables. Une charge de travail nécessitant de nombreuses adresses favorise brièvement la tarification au trafic ; une charge de travail nécessitant peu d’adresses favorise fortement la tarification par adresse IP. Nous avons détaillé ces calculs dans le guide de tarification des proxys.

Règles empiriques et leurs limites

Si vous avez besoin d’un point de départ avant de procéder à des mesures, celles-ci sont défendables. Considérez-les comme une première estimation à remplacer, et non comme une réponse définitive.

Deux chiffres à retenir. Presque aucune charge de travail ne nécessite plus de quelques dizaines d’adresses simultanées, et celles qui en ont réellement besoin sont soit de nature géographique (nombreux emplacements, faible volume chacun), soit soumises à une échéance que l’on s’est soi-même imposée. Et le paramètre qu’il faut le plus souvent modifier n’est pas le nombre d’adresses, mais le calendrier.

Signes indiquant que vous vous êtes trompé de chiffre

Trop peu se traduit par : une augmentation des 429, l'apparition de problèmes, un taux de réussite en baisse au fur et à mesure que le cycle avance, des tâches qui se terminent plus tard que prévu. La solution consiste à augmenter la concurrence ou à allonger la fenêtre.

Trop ne se traduit par : rien. C'est pourquoi l'erreur persiste. Un pool surdimensionné ne produit aucun symptôme sur la tarification au trafic, donc personne ne s’en rend compte. Avec la tarification par adresse IP, cela génère une facture, ce qui soulève au moins la question.

Deux situations qui ressemblent à un « nombre insuffisant » mais qui n’en sont pas :

Un pool bloqué. Si le taux de réussite s’effondre simultanément sur toutes les adresses, en ajouter d’autres ne servira à rien : soit quelque chose a changé au niveau de la cible, soit le profil de vos requêtes est identifié à partir d’un signal autre que l’adresse.

Une cible lente. Si les réponses sont lentes mais aboutissent, une concurrence accrue améliorera le débit jusqu’à un certain point, puis cessera d’avoir d’effet. Mesurez le nombre de requêtes traitées par seconde et cessez d’augmenter la concurrence lorsque ce chiffre se stabilise, ce qui se produira plus tôt que prévu.

Diagnostic général : augmentez la concurrence par paliers et observez le nombre de réponses utiles traitées par seconde. Ce chiffre augmente, se stabilise, puis diminue. Le point optimal correspond à cette stabilisation, et il s’agit généralement d’un chiffre inférieur à ce que l’on pourrait prévoir.

Questions fréquentes

De combien de proxys ai-je besoin pour le web scraping ?

Mieux vaut mesurer que deviner : déterminez le taux de requêtes à partir duquel une seule adresse commence à être limitée sur votre cible réelle, divisez le débit dont vous avez besoin par ce chiffre, puis ajoutez une marge. La plupart des charges de travail se situent entre un chiffre et quelques dizaines d’adresses simultanées, et non pas des milliers.

Est-ce que le fait d’utiliser davantage de proxys réduit le risque d’être bloqué ?

Uniquement si le blocage est spécifique à une adresse. Si vos requêtes sont identifiées comme automatisées en raison de leur timing, de la composition de leurs en-têtes ou de leur empreinte TLS, multiplier le nombre d’adresses ne fait que répartir ce même signal sur une plus grande partie de votre pool, plutôt que de le contourner. Le débit et la forme des requêtes importent davantage que leur nombre.

Combien de proxys faut-il pour 1 million de requêtes par jour ?

Cela dépend entièrement de la fenêtre temporelle. Réparties sur 24 heures, cela représente environ 12 requêtes par seconde, ce qui, à raison d’une requête toutes les deux secondes par adresse, correspond à environ 25 adresses simultanées. Si l’on concentre ce volume sur deux heures, ce chiffre est multiplié par douze. C’est le calendrier qui est la variable, pas le volume.

Ai-je besoin d’un proxy par compte ?

Pour tout ce qui repose sur des sessions, il faut une adresse « sticky » par session simultanée — et non par compte. Dix comptes utilisés séquentiellement au cours de la journée ne nécessitent dix adresses que si les dix sont actifs simultanément. Notez que de nombreuses plateformes interdisent explicitement l’utilisation de plusieurs comptes ; vérifiez donc les conditions d’utilisation avant de concevoir une stratégie en tenant compte de cette contrainte.

Vaut-il mieux disposer d’un plus grand nombre d’adresses IP ou d’adresses IP de meilleure qualité ?

« Meilleures », c’est-à-dire bien réparties entre les sous-réseaux et adaptées à la cible. Le blocage se produit généralement au niveau de l’/24, de sorte que cinquante adresses d’un même bloc se comportent comme une seule. Un pool plus petit et bien réparti est plus performant qu’un pool plus grand mais concentré.

Comment savoir si je dispose de trop peu de proxys ?

Une augmentation des codes d’erreur 429, l’apparition de pages de vérification d’authenticité et une baisse du taux de réussite au fur et à mesure de l’exécution. Si le taux de réussite s’effondre simultanément sur toutes les adresses, il s’agit d’un problème différent : soit quelque chose a changé au niveau de la cible, soit vos requêtes sont identifiées à partir d’un signal autre que l’adresse, et disposer de plus d’adresses n’y changera rien.

Le nombre de proxys a-t-il une incidence sur le prix ?

Dans le cadre d’une tarification à l’adresse IP, directement : vous achetez le nombre d’adresses. Dans le cadre d’une tarification au gigaoctet, pas du tout, car vous payez pour les données et le nombre d’adresses est une caractéristique du pool. C’est pourquoi ces deux modèles ne peuvent pas être comparés sur la base des tarifs affichés.

Combien de proxys faut-il pour le ciblage géographique ?

Une sortie fiable par emplacement dont vous avez besoin, et le volume n’a généralement aucune importance. La question à poser à un fournisseur n’est pas de savoir combien d’adresses il possède, mais s’il dispose d’une couverture fiable sur vos marchés spécifiques, et si vous pouvez la tester avant de vous engager.

Conclusion

Le chiffre dont vous avez besoin résulte d’une mesure et d’une division : déterminez à partir de quelle adresse une limitation de débit commence à s’appliquer sur votre cible réelle, puis divisez votre besoin de débit par ce chiffre. Tout le reste n’est qu’affinage.

La variable qui détermine le résultat n’est pas le volume, mais la fenêtre temporelle que vous accordez. Cinquante mille pages par jour nécessitent quelques adresses réparties sur vingt-quatre heures, et vingt sur deux. Avant d’acheter de la capacité pour aller plus vite, vérifiez si quoi que ce soit dépend réellement d’une exécution plus rapide de la tâche — souvent, ce n’est pas le cas, et l’optimisation la moins coûteuse qui soit est la patience.

Et pour les activités géographiques, la question prend une toute autre dimension. Le volume est insignifiant, la présence est primordiale, et l’évaluation pertinente consiste à déterminer si un fournisseur couvre de manière fiable vos marchés spécifiques plutôt que l’importance de son parc. Cela peut être vérifié lors d’un essai : cela prend un après-midi et vous en apprendra davantage que n’importe quel chiffre affiché par un fournisseur sur sa page d’accueil — y compris la nôtre.