La plupart des gens qui achètent des proxies pour la première fois abordent la question comme un choix unique, quel plan choisir, et finissent par décider uniquement sur le prix. Cela produit généralement l’un de deux résultats : un plan trop petit pour le travail, découvert à mi-parcours du mois, ou un plan acheté pour une capacité qui n’est jamais utilisée. Aucun des deux n’est vraiment une erreur de tarification. Ils résultent du fait d’avoir sauté les deux décisions qui devraient précéder tout regard sur le prix.
Bien choisir revient à trois décisions dans l’ordre : quel type de proxy votre projet nécessite, combien de bande passante ce projet va réellement consommer, et quelles fonctionnalités sont véritablement requises plutôt que simplement listées. Prenez ces décisions correctement et le plan se choisit de lui-même.
Décision une : quel produit votre projet nécessite
Les types de produits ne sont pas des niveaux d’une même chose. Ils se comportent différemment, et choisir le mauvais ne peut pas être corrigé en en achetant davantage.
Le résidentiel rotatif est le choix par défaut pour la collecte de données. Vous puisez dans un large pool d’adresses domestiques réelles, et par défaut chaque requête sort par une adresse différente, ce qui répartit votre volume pour qu’aucune adresse unique n’attire l’attention. Choisissez cette option quand le travail est du scraping, de la surveillance de prix ou de disponibilité, de la collecte SERP et de classement, de la vérification publicitaire, ou tout travail dont la forme est de nombreuses requêtes réparties sur de nombreuses cibles ou marchés.
Le résidentiel statique, ou proxies ISP, sont des adresses hébergées enregistrées auprès d’un fournisseur d’accès internet grand public, elles portent donc une confiance de niveau résidentiel tout en restant identiques dans le temps. Choisissez cette option quand la persistance est l’exigence plutôt que le volume : gérer des comptes qui doivent toujours être vus depuis la même adresse, des sessions de longue durée, ou tout cas où une adresse qui change sous vous constitue le problème plutôt que la solution. Le compromis est traité dans ISP versus résidentiel et qu’est-ce que les proxies résidentiels statiques.
Le datacenter est le moins cher et le plus rapide, et c’est la bonne réponse quand vos cibles ne s’en soucient pas. Si vous visez une API ouverte, votre propre infrastructure, ou des sites sans défenses significatives, payer des prix résidentiels est du gaspillage. La comparaison honnête se trouve dans résidentiel versus datacenter.
La règle pratique consiste à utiliser le type le moins cher qui passe de manière fiable vos cibles réelles, et à l’établir par des tests plutôt que par des suppositions. Beaucoup de projets finissent mixtes : datacenter pour les sources faciles, résidentiel pour les défendues.
Décision deux : combien de bande passante
Les proxies résidentiels sont facturés selon les données transférées plutôt que selon le nombre d’adresses que vous touchez, donc la bande passante est le chiffre qui détermine votre plan. Le raisonnement derrière ce modèle se trouve dans pourquoi l’ère du prix par port est révolue, et la méthode de dimensionnement est simple.
Estimez la taille moyenne d’une réponse de vos cibles, multipliez par le nombre de requêtes que vous prévoyez dans un mois, et ajoutez une marge pour les nouvelles tentatives et les échecs. Une page HTML simple ou une réponse d’API JSON fait généralement quelques dizaines de kilo-octets ; une page complète rendue dans un navigateur, avec images, polices et scripts, peut faire plusieurs mégaoctets, ce qui constitue la variable la plus importante de tout le calcul. Dix mille appels JSON par jour donnent un plan très différent de dix mille pages entièrement rendues par jour, et la différence est d’environ deux ordres de grandeur. La méthode détaillée se trouve dans estimer la bande passante mensuelle.
Deux choses réduisent le chiffre avant l’achat. Récupérer le point de terminaison de données sous-jacent plutôt que de rendre la page entière est le levier le plus important, et bloquer les images, les médias et les polices quand vous devez vraiment rendre la page est le deuxième, tous deux traités dans réduire les coûts de bande passante proxy. Il vaut la peine de faire cette optimisation avant de dimensionner un plan, car elle peut vous faire descendre d’un niveau.
Notez ce qui ne figure pas dans cette liste : le nombre d’IP que vous obtenez. Sur un réseau mutualisé, ce n’est pas la quantité que vous achetez, et le raisonnement se trouve dans combien d’IP proxy avez-vous réellement besoin. La seule exception concerne les sessions persistantes simultanées, qui constituent une exigence réelle à préciser si votre travail nécessite des identités maintenues.
Décision trois : quelles fonctionnalités sont réellement requises
Les listes de fonctionnalités sont l’endroit où les plans commencent à paraître compliqués. La plupart se réduit à cinq questions.
La granularité géographique. Le ciblage par pays couvre la plupart des projets. Si votre travail dépend de résultats locaux, de prix locaux, ou de données au niveau du magasin, vous avez besoin du ciblage au niveau de la ville, et si vous traitez un comportement spécifique à un opérateur, vous avez besoin du ciblage ASN. Vérifiez que les pays qui vous intéressent sont bien couverts, pas seulement qu’un grand nombre global est annoncé.
Le contrôle de session. Confirmez que vous pouvez à la fois faire tourner par requête et maintenir une session persistante quand un flux en plusieurs étapes en a besoin. La plupart des projets réels ont besoin des deux à des moments différents.
La concurrence. Demandez quelle limite s’applique aux connexions simultanées, car un plan qui mesure la concurrence séparément va étrangler un travail qu’un plan uniquement basé sur la bande passante exécuterait sans problème. Voir connexions simultanées illimitées.
Protocoles et intégration. HTTP et SOCKS5 couvrent presque tout ; ce qui compte davantage, c’est que le ciblage puisse s’exprimer d’une manière que votre stack peut piloter par requête, ce qui sur une passerelle signifie des identifiants dans le nom d’utilisateur plutôt qu’un bouton de tableau de bord.
Tout le reste est généralement secondaire jusqu’à ce que vous opériez à grande échelle, moment où la réactivité du support et la flexibilité de facturation commencent à compter plus que n’importe quelle case fonctionnalité.
Faire correspondre les formes de projets courantes aux plans
Quelques schémas couvrent la plupart des premiers achats.
Un petit projet de recherche ou de surveillance, suivant quelques centaines de pages par jour, représente typiquement quelques gigaoctets par mois sur du résidentiel rotatif avec ciblage par pays. Commencez par le plus petit niveau qui couvre votre estimation avec une marge, car monter en gamme plus tard est facile et acheter un grand niveau pour un projet non encore validé ne l’est pas.
Un pipeline de scraping en production sur de nombreuses cibles est l’endroit où l’estimation de bande passante prouve son utilité, et où le travail d’optimisation se rentabilise directement. Dimensionnez selon l’usage mesuré lors d’un essai plutôt que sur une estimation, et attendez-vous à ce que le chiffre réel diffère de votre estimation dans les deux sens.
Le travail basé sur des comptes ou des sessions oriente vers des adresses ISP statiques et un nombre déclaré de sessions simultanées plutôt qu’un large pool rotatif.
Les charges de travail mixtes sont courantes et acceptables : datacenter pour les sources non défendues, résidentiel pour le reste. Dimensionner chacune séparément coûte moins cher que de tout faire passer par la voie coûteuse.
Valider avant de s’engager
Quelle que soit votre conclusion, traitez-la comme une hypothèse et testez-la sur un essai ou un premier petit achat avant de passer à l’échelle. Exécutez vos cibles réelles, pas une URL de test générique, et mesurez le taux de réussite avec une validation de réponse plutôt qu’avec les seuls codes de statut, car une page de défi renvoyée avec un 200 ressemblera sinon à un succès. Confirmez que la géographie que vous avez payée est bien celle que vous obtenez. Mesurez les octets réels par requête pour que votre estimation de bande passante devienne une mesure. La méthode se trouve dans tester la vitesse, le taux de réussite et la précision de localisation, et les critères au niveau du fournisseur sont dans comment choisir un réseau proxy.
Une semaine d’usage réel vous en apprend plus que n’importe quelle fiche technique, et elle transforme les trois décisions ci-dessus, d’estimations en faits.
En résumé
Choisissez le type de produit selon ce qu’exigent vos cibles, pas selon le prix : résidentiel rotatif pour le volume et la géographie, ISP statique pour la persistance, datacenter là où les cibles ne s’en soucient pas. Dimensionnez le plan selon la bande passante, c’est-à-dire en estimant la taille de réponse multipliée par le volume de requêtes et en optimisant ce que vous récupérez avant l’achat, car cela seul peut vous faire descendre d’un niveau. N’exigez que les fonctionnalités que votre projet utilise réellement, la granularité géographique et le contrôle de session étant les deux qui comptent le plus souvent. Puis validez sur des cibles réelles avant de passer à l’échelle, car l’usage mesuré bat toute estimation.
Si cela vous oriente vers le résidentiel rotatif, les proxies résidentiels offrent un ciblage par pays et par ville, une rotation par défaut, et des sessions persistantes quand un flux en a besoin, avec une tarification par Go pour que le plan suive les données que vous déplacez réellement plutôt qu’un nombre de sièges ou une allocation de ports.